Всем привет!
(Простите модераторы если угадил не в тот раздел.)
Есть такой вопрос.
Надо написать кросплатформенную программу, с GUI.
Начал копаться в разных библиотеках, нарыл wxWidgets, Qt4
поставил обе. Посмотрел на обе. Вроде обе ничего, но это лишь первое мнение,
так как глубоко я их не копал.
просто скомпиллил пару тестов юзая обе библиотеки.
1. wxWidgets — на первый взгляд мне показалось что имею дело с MFC. только без эдитора.
Даже в нете нашел аналогию классов этих двух библиотек. В сочетании с DialogBlocks и Visual Studio
можно сносно работать. Сдизайнил в Блоках, обновились файлы в студии, и пиши себе дальше.
Вроде бы все нормально
2. Qt4 — Ну на ней все KDE написано, хотя из этого ничего не следует
проинтегрировал в Вижцал Студио, в принципе приятно. Но с ней пока не разбирался надлежащим образом.
FLTK — только слышал про эту библиотеку. Вот тут о ней очен хорошо отзываются.
Так вот, Всемогущий Олл!!!
Мне нужно знать следующее, с какой библиотекой проще работать, то есть не тратить время на лобовой кодинг контролов, то есть их размещения и все такое.
интересует так же вопрос портируемости программ , написанных на этих библиотеках на другие Оси.
Интереует вопрос скорости каждой библиотеки, то есть не станет ли программа джава-подобной (простите , никого не хотел обидеть)?
Что лучше?
Здравствуйте, Sorantis, Вы писали:
S>Всем привет! S>(Простите модераторы если угадил не в тот раздел.)
S>Есть такой вопрос. S>Надо написать кросплатформенную программу, с GUI. S>Начал копаться в разных библиотеках, нарыл wxWidgets, Qt4 S>поставил обе. Посмотрел на обе. Вроде обе ничего, но это лишь первое мнение, S>так как глубоко я их не копал. S>просто скомпиллил пару тестов юзая обе библиотеки.
S>1. wxWidgets — на первый взгляд мне показалось что имею дело с MFC. только без эдитора. S>Даже в нете нашел аналогию классов этих двух библиотек. В сочетании с DialogBlocks и Visual Studio S>можно сносно работать. Сдизайнил в Блоках, обновились файлы в студии, и пиши себе дальше. S>Вроде бы все нормально
S>2. Qt4 — Ну на ней все KDE написано, хотя из этого ничего не следует S>проинтегрировал в Вижцал Студио, в принципе приятно. Но с ней пока не разбирался надлежащим образом.
S>FLTK — только слышал про эту библиотеку. Вот тут о ней очен хорошо отзываются.
S>Так вот, Всемогущий Олл!!! S>Мне нужно знать следующее, с какой библиотекой проще работать, то есть не тратить время на лобовой кодинг контролов, то есть их размещения и все такое. S>интересует так же вопрос портируемости программ , написанных на этих библиотеках на другие Оси. S>Интереует вопрос скорости каждой библиотеки, то есть не станет ли программа джава-подобной (простите , никого не хотел обидеть)? S>Что лучше?
Вот уже который год пишу на wxWidgets и доволен как слон.
Подавляющее большинство задач вполне неплохо можно решить средствами самой библиотеки или же с помощью сторонних компонентов-дополнений. Но опять же, никто не мешает использовать родное API для каждой ОСи, отделяя платоформо-зависимый код с помощью директив препроцессора.
Как по мне, wxWidgets — отличное решение.
S>Меня интресеуют те проблемы с которыми вы сталкивались использую приведенные мною библиотеки. S>Какие минусы есть у Qt и какие у wxWidgets?
я с drag&drop'ом в wxWidgets долго боролся, потом сделал как в винде, платформ. зависимо в общем получилось
> S>Меня интресеуют те проблемы с которыми вы сталкивались использую приведенные мною библиотеки. > S>Какие минусы есть у Qt и какие у wxWidgets? > я с drag&drop'ом в wxWidgets долго боролся, потом сделал как в винде, платформ. зависимо в общем получилось
Странно, а с чем там бороться? Вроде все просто делается.
Posted via RSDN NNTP Server 2.0
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Sergey, Вы писали:
>> S>Меня интресеуют те проблемы с которыми вы сталкивались использую приведенные мною библиотеки. >> S>Какие минусы есть у Qt и какие у wxWidgets? >> я с drag&drop'ом в wxWidgets долго боролся, потом сделал как в винде, платформ. зависимо в общем получилось
S>Странно, а с чем там бороться? Вроде все просто делается.
Я уже не помню точно, но таскать нужно было файлы в проводник (и др.) и из него. Хотел сделать cut, copy, paste и link.
S>Меня интресеуют те проблемы с которыми вы сталкивались использую приведенные мною библиотеки. S>Какие минусы есть у Qt и какие у wxWidgets?
До последнего релиза (2.7.0) очень напрягало отсутствие какого-либо DBGrid-контрола. В последнем релизе какая-то корявка появилась, но меня терзают смутные сомнения по поводу ее стабильности. Думаю к стабильному релизу 2.8.x его доведут до работоспособного состояния.
Еще были проблемы с использованием контролов созданных внутри плагинов (когда внутри DLL создаем контрол и вешаем его на главную форму приложения). Решения так и не нашел, хотя имел достаточно оживленную беседу с разработчиками wxWidgets.
> Еще были проблемы с использованием контролов созданных внутри плагинов (когда внутри DLL создаем контрол и вешаем его на главную форму приложения). Решения так и не нашел, хотя имел достаточно оживленную беседу с разработчиками wxWidgets.
А это кстати проблема вообще всех кроссплатформенных библиотек, что я видел (смотрел года 3 назад). И в QT (QT4 я естественно не смотрел, не было ее еще), и в FLTK, и еще в 2-3 либах (названия уже не помню) какой-либо осмысленной работы с hInstance не наблюдается. Хотя при некотором усердии вред от этого минимален.
Posted via RSDN NNTP Server 2.0
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Sorantis, Вы писали:
S>Всем привет! S>(Простите модераторы если угадил не в тот раздел.)
В свое время выбирал между Qt и wxWidgets. В wx напугала документация(не в пример Qt, у Qt документация — просто сказка ) и необходимость активно использовать макросы — поэтому выбор пал не в его пользу. Wx, говорят, написан в стиле "С с объектами".. Qt же написан в лучших традициях С++(разве что исключения не использует) — в своем коде я часто наследуюсь от Qt классов, чтобы сделать маленький, заточенный под себя тюнинг.
Qt к тому же не просто gui lib, а уже почти целый framework — в нем есть и работа с ФС, с сестью, XML, threads, ActiveX, IPC какое-то тоже есть.. вообщем советую присмотрется .
Здравствуйте, xk, Вы писали:
xk>Здравствуйте, Sorantis, Вы писали:
S>>Всем привет! S>>(Простите модераторы если угадил не в тот раздел.)
xk>В свое время выбирал между Qt и wxWidgets. В wx напугала документация(не в пример Qt, у Qt документация — просто сказка ) и необходимость активно использовать макросы — поэтому выбор пал не в его пользу. Wx, говорят, написан в стиле "С с объектами".. Qt же написан в лучших традициях С++(разве что исключения не использует) — в своем коде я часто наследуюсь от Qt классов, чтобы сделать маленький, заточенный под себя тюнинг.
ну не знаю, меня документация в wxWidgets полностью устраивает. Как грится, на вкус и цвет... фломастеры разные.
xk>Qt к тому же не просто gui lib, а уже почти целый framework — в нем есть и работа с ФС, с сестью, XML, threads, ActiveX, IPC какое-то тоже есть.. вообщем советую присмотрется .
Мммм... да и в wxWidgets это всё тоже есть.. к тому же она неплохо прогрессирует и в каждом новом релизе все больше полезностей появляется. Например в последнем добавили библиотеку с плавающими окнами.. очень симпатичные и скинабельные к тому же.
Здравствуйте, Sergey, Вы писали:
>> Еще были проблемы с использованием контролов созданных внутри плагинов (когда внутри DLL создаем контрол и вешаем его на главную форму приложения). Решения так и не нашел, хотя имел достаточно оживленную беседу с разработчиками wxWidgets.
S>А это кстати проблема вообще всех кроссплатформенных библиотек, что я видел (смотрел года 3 назад). И в QT
Не знаю что было 3 года назад но 1 год назад я рботал с QT 3.x
Никаких проблемм с этим не было. У нас апликуха на этом и строилась что виджеты были в плагинах....
С уважением Denys Valchuk
IMHO чем больше мнений тем оптимальней выбор варианта... :)
Здравствуйте, Sorantis, Вы писали:
S>Есть такой вопрос. S>Надо написать кросплатформенную программу, с GUI. S>Начал копаться в разных библиотеках, нарыл wxWidgets, Qt4 S>поставил обе. Посмотрел на обе. Вроде обе ничего, но это лишь первое мнение, S>так как глубоко я их не копал. S>просто скомпиллил пару тестов юзая обе библиотеки.
Я б вам посоветовал не обращать внимания на тезисы, аля: "Я использую n лет — всё классно!".
Человек может пишет аппликухи, аля СD ejecter и его она вполне устраивает
Я тут даже спорить не стану.
У всех задачи разные... У всех разные требования.
Ваши требования — аля быстрая штамповка формочек для кроссплатформенного приложения... Слегка не точны...
1. Как много платформ вы собираетесь поддерживать? (и какие)
2. Требуется ли вам нативность интерфейса или его единообразность?
3. Насколько интерфейс богат кастомными контролами?
4. Является ли для вас цена библиотеки определяющим фактором?
Поверьте... Я не первый год занимаюсь кроссплатформенной разработкой на с++... Эти вопросы важны...
А RAD на самом деле не столь важно как суппорт к примеру
С уважением Denys Valchuk
IMHO чем больше мнений тем оптимальней выбор варианта... :)
Здравствуйте, Dj.ValDen, Вы писали:
DV>Здравствуйте, Sergey, Вы писали:
>>> Еще были проблемы с использованием контролов созданных внутри плагинов (когда внутри DLL создаем контрол и вешаем его на главную форму приложения). Решения так и не нашел, хотя имел достаточно оживленную беседу с разработчиками wxWidgets.
S>>А это кстати проблема вообще всех кроссплатформенных библиотек, что я видел (смотрел года 3 назад). И в QT DV>Не знаю что было 3 года назад но 1 год назад я рботал с QT 3.x DV>Никаких проблемм с этим не было. У нас апликуха на этом и строилась что виджеты были в плагинах....
Интересно... сейчас проблема заключается в том что контрол из первой загруженной библиотеки не обрабатывает события.. все остальные контролы чудесно работают.
Мммм.. и вопрос в таком случае вдогонку... а можно как-нибудь взглянуть на скелетик приложения (или той части) который(ая) отвечает за подгрузку плагинов?
Собственно, у меня это выглядело вот таким образом: http://rapidshare.de/files/29427010/PluggableGUI.rar.html
[поскипано частично]
DV>А RAD на самом деле не столь важно как суппорт к примеру
У того же DialogBlocks by Julian Smart суппорт вполне неплохо можно получить и общаясь с самими Julian Smart (плюс ко всему он еще и среди разработчиков библиотеки числится) да и апдейты данной тулзы выпускаются довольно часто (вслед за изменениями в библиотеке или по приходу багрепортов)
DV>1. Как много платформ вы собираетесь поддерживать? (и какие) DV>2. Требуется ли вам нативность интерфейса или его единообразность? DV>3. Насколько интерфейс богат кастомными контролами?
А вот суппорт у кастомных контролов, особенно у бесплатных овпенсорсных зачастую хромает на все конечности... хотя всякого рода патчи и віпускаются время от времени.
DV>4. Является ли для вас цена библиотеки определяющим фактором?
Плюс хотелось бы добавить что стоит также подумать, будет ли необходимость в интеграции уже существующего нативного кода в разрабатываемый проект и каких усилий это будет стоить (а также посмотреть на наличие уже готовых кросс-платформенных решений и оценить целесообразность использования именно этих решений, вместо реализации требуемого функционала с помощью родного API для каждой платформы)
Дальше. Относительно средств разработки та же wxWidgets чудеснейшим образом работает c MinGW/GCC/VC++ но с Borland C++ получаем кучу глюков и/или артефактов, наличие которых было подтверждено также и при общении с wxWidgets-девелоперами из других компаний.
DV>Поверьте... Я не первый год занимаюсь кроссплатформенной разработкой на с++... Эти вопросы важны...
+1
>>> Еще были проблемы с использованием контролов созданных внутри плагинов (когда внутри DLL создаем контрол и вешаем его на главную форму приложения). Решения так и не нашел, хотя имел достаточно оживленную беседу с разработчиками wxWidgets. > > S>А это кстати проблема вообще всех кроссплатформенных библиотек, что я видел (смотрел года 3 назад). И в QT > Не знаю что было 3 года назад но 1 год назад я рботал с QT 3.x > Никаких проблемм с этим не было. У нас апликуха на этом и строилась что виджеты были в плагинах....
В целом оно работает, да. Только, например, API вызов UnregisterClass для оконных классов из dll не проходил. Это, конечно, всего лишь мелкие утечки, но все равно неприятно. Но меня больше другая проблема напрягала — в результате наличия всего одного экземпляра hInstance на всю библиотеку виндовые ресурсы только из одной dll'ки грузились. Ну и получалось иногда, что то в одном контроле кисть для рисования его задизейбленным не прогрузилась, то в другом контекстного меню нету
Posted via RSDN NNTP Server 2.0
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Dj.ValDen, Вы писали:
DV>Здравствуйте, Sorantis, Вы писали:
S>>Есть такой вопрос. S>>Надо написать кросплатформенную программу, с GUI. S>>Начал копаться в разных библиотеках, нарыл wxWidgets, Qt4 S>>поставил обе. Посмотрел на обе. Вроде обе ничего, но это лишь первое мнение, S>>так как глубоко я их не копал. S>>просто скомпиллил пару тестов юзая обе библиотеки.
DV>Я б вам посоветовал не обращать внимания на тезисы, аля: "Я использую n лет — всё классно!". DV>Человек может пишет аппликухи, аля СD ejecter и его она вполне устраивает DV>Я тут даже спорить не стану.
DV>У всех задачи разные... У всех разные требования. DV>Ваши требования — аля быстрая штамповка формочек для кроссплатформенного приложения... Слегка не точны...
Мои требование таковы : Портируемость приложения на любую платформу без радикальных изменений кода. Не хочу юзать предефайны для конкретных Осей. Хотелось бы получить полную кросплатформенность. DV>1. Как много платформ вы собираетесь поддерживать? (и какие)
Платформы : Windows, Linux (RedHat, Suse, Debian, etc.), FreeBSD, MacOS DV>2. Требуется ли вам нативность интерфейса или его единообразность?
В принципе это не думаю чтобы оказалось важным. так как собираюсь писать не Мессенджер какой-нибудь, или что-то подобное. DV>3. Насколько интерфейс богат кастомными контролами?
Это в зависимости от библиотек, например у Qt много кастом контролов своих же. Но опять таки, если понадобится кастомный контрол , то буду наследоваться с похожего базового контрола и дорабатывать его под свои нужды. DV>4. Является ли для вас цена библиотеки определяющим фактором?
Вопрос интересный в принципе это вопрос к заказчику.
DV>Поверьте... Я не первый год занимаюсь кроссплатформенной разработкой на с++... Эти вопросы важны...
Согласен. DV>А RAD на самом деле не столь важно как суппорт к примеру
Здравствуйте, Sorantis, Вы писали:
S>Мои требование таковы : Портируемость приложения на любую платформу без радикальных изменений кода. Не хочу юзать предефайны для конкретных Осей. Хотелось бы получить полную кросплатформенность.
однозначно QT
DV>>1. Как много платформ вы собираетесь поддерживать? (и какие) S>Платформы : Windows, Linux (RedHat, Suse, Debian, etc.), FreeBSD, MacOS DV>>2. Требуется ли вам нативность интерфейса или его единообразность? S>В принципе это не думаю чтобы оказалось важным. так как собираюсь писать не Мессенджер какой-нибудь, или что-то подобное.
Если вы включаете в суппорт MacOS То важно. Ибо там интерефейс приемлем только маковский (тоесть нативный). К примеру Open Office там никто не юзает
Если вы действительно собрались суппортить MacOS — смотрите в сторону QT. Только она, из всех перечисленных вами, нормально на нём работает.
Linux (RedHat, Suse, Debian, etc.), FreeBSD — в смысле GUI можно объединить в одно и тоже У них у всех X Server. DV>>3. Насколько интерфейс богат кастомными контролами? S>Это в зависимости от библиотек, например у Qt много кастом контролов своих же. Но опять таки, если понадобится кастомный контрол , то буду наследоваться с похожего базового контрола и дорабатывать его под свои нужды.
Нет... Это в зависимости от ваших требований к интерфейсу — следует выбирать библиотеку.
Потому как естессно Button у всех библиотек есть
А вот копнуть глубже... К примеру в wxWidgets очень мало контролов портировано на Mac. А контрол для работы с форматированным текстом вообще нормально работает только под виндой... Вы хотите дописывать сами?
В QT же, Если есть контрол — он есть на всех поддерживаемых системах.
FLTK... Её можете даже не смотреть — у неё нету маковского интерфейса вообще и в принципе... Если у wxWidgets кто то что то начинал... То с пом FLTK вы получите на маке виндовые окошки — и вашу аппликуху юзеры просто выбросят после первого запуска
DV>>4. Является ли для вас цена библиотеки определяющим фактором? S>Вопрос интересный в принципе это вопрос к заказчику.
Тогда советую собрать убедительный список из плюсов QT
+ ткнуть в сторону успешных решений Аля Opera, Skype, AOL ...
И убедить заказчика приобрести QT.
Выбирать между QT, wxWidgets, FLTK, FOX можно только в том случае если вы суппортить собрались Windows и Linux(FreeBSD ... etc)
Если же список больше... ( и в планах поддержка кастомных устройств. ) — QT и только QT.
С уважением Denys Valchuk
IMHO чем больше мнений тем оптимальней выбор варианта... :)
Спасибо большое за полезный ответ
У меня есть еще парочка вопросов.
А как на счет скорости работы? Мне сказали что Qt тормознутее остальных кросплатформенных библиотек.
Что Вы можете сказать на счет этого?
wxWidgets фактчески обертка для нативных библиотек операционных систем. Поэтому можно предположить что скорость работы у этой библиотеки будет не меньше , чем у библиотек самих систем.
Qt же в свою очередь является так сказать фреймворком.
Не возникнут ли неоправданные тормоза у программы написанной на Qt?
DV>Здравствуйте, Sorantis, Вы писали:
S>>Мои требование таковы : Портируемость приложения на любую платформу без радикальных изменений кода. Не хочу юзать предефайны для конкретных Осей. Хотелось бы получить полную кросплатформенность. DV>однозначно QT
DV>>>1. Как много платформ вы собираетесь поддерживать? (и какие) S>>Платформы : Windows, Linux (RedHat, Suse, Debian, etc.), FreeBSD, MacOS DV>>>2. Требуется ли вам нативность интерфейса или его единообразность? S>>В принципе это не думаю чтобы оказалось важным. так как собираюсь писать не Мессенджер какой-нибудь, или что-то подобное.
DV>Если вы включаете в суппорт MacOS То важно. Ибо там интерефейс приемлем только маковский (тоесть нативный). К примеру Open Office там никто не юзает DV>Если вы действительно собрались суппортить MacOS — смотрите в сторону QT. Только она, из всех перечисленных вами, нормально на нём работает. DV>Linux (RedHat, Suse, Debian, etc.), FreeBSD — в смысле GUI можно объединить в одно и тоже У них у всех X Server. DV>>>3. Насколько интерфейс богат кастомными контролами? S>>Это в зависимости от библиотек, например у Qt много кастом контролов своих же. Но опять таки, если понадобится кастомный контрол , то буду наследоваться с похожего базового контрола и дорабатывать его под свои нужды. DV>Нет... Это в зависимости от ваших требований к интерфейсу — следует выбирать библиотеку. DV>Потому как естессно Button у всех библиотек есть DV>А вот копнуть глубже... К примеру в wxWidgets очень мало контролов портировано на Mac. А контрол для работы с форматированным текстом вообще нормально работает только под виндой... Вы хотите дописывать сами? DV>В QT же, Если есть контрол — он есть на всех поддерживаемых системах.
DV>FLTK... Её можете даже не смотреть — у неё нету маковского интерфейса вообще и в принципе... Если у wxWidgets кто то что то начинал... То с пом FLTK вы получите на маке виндовые окошки — и вашу аппликуху юзеры просто выбросят после первого запуска
DV>>>4. Является ли для вас цена библиотеки определяющим фактором? S>>Вопрос интересный в принципе это вопрос к заказчику.
DV>Тогда советую собрать убедительный список из плюсов QT DV>+ ткнуть в сторону успешных решений Аля Opera, Skype, AOL ... DV>И убедить заказчика приобрести QT.
DV>Выбирать между QT, wxWidgets, FLTK, FOX можно только в том случае если вы суппортить собрались Windows и Linux(FreeBSD ... etc) DV>Если же список больше... ( и в планах поддержка кастомных устройств. ) — QT и только QT.
