Цель статьи
- Рассказать о своем опыте разработки ПО с использованием wxWidgets.
- Поделиться готовым решением в области подготовки и печати шаблонов документов.
- Получить рекомендации и конструктивную критику по функционалу.
Но сначала история
Итак, однажды, работая на одном из промышленных предприятий, которое имело собственное оборудование для коммерческого учета нефти, со своими программными решениями под разными ОС, все чаще и чаще стал задумываться над кроссплатформенной разработкой ПО.
Хлебнул я тогда разных библиотек. Были в этом списке и Gtk+, и QT. Но по настоящему, меня привлекла wxWidgets.
Был у меня в то же время частный проект БД для фирмы, которая занималась сопровождением сделок по купле-продаже автомобилей, страхованием, ТО. Его я делал по выходным. На начальном этапе, этого проекта я и опробовал QT, Gtk+, wxWidgets, но в итоге полностью заново реализовал при помощи других инструментов, потому как:
Терпение — прекрасное качество, но жизнь слишком коротка, чтобы долго терпеть — Абу-ль-Фарадж.
На тот момент причиной отказа от использования этих библиотек было ограничение по времени, а не сложность технической реализации. Бизнес ждать не любит.
В общем, при разработке этого проекта для каждой опробованной библиотеки я достиг определенного уровня завершенности. В таблице указаны результаты в порядке возрастания.
| Инструмент | Что было сделано | Отзыв от заказчика | Причина отказа |
|---|---|---|---|
| QT | Пара форм + обвязка их логикой. | Заказчику не представлен. | Много времени тратил на поиск решения. |
| Gtk+ | Весь GUI. | Для WinXP GUI выглядел не как родной и привычный. | Не хватало построителя GUI, интегрированного в IDE. Не привычный вид GUI. Громоздкость реализации, длинные имена функций. Много времени тратил на поиск решения. |
| wxWidgets | Весь GUI + БД. | Не было печати документов с точным позиционированием элементов. | Не было готового генератора шаблонов документов для печати. |
Были и другие, но их результаты еще скромнее, чем у QT.
Справедливости ради надо сказать, что это было первый опыт использования всех этих библиотек. Если бы не генератор шаблонов документов для печати в wxWidgets…
Что теперь?
В итоге совсем недавно я сделал минимально-жизнеспособный кроссплатформенный генератор шаблонов и клиентскую библиотеку для печати с использованием wxWidgets на том уровне, которого мне бы хватило тогда.
Желающие попробовать могут взять тут: c-help.tk. Сайт мне любезно предоставил брат, я его попросил оформить максимально упрощенно и без изысков. Надеюсь, у нас получилось.
Что имеем на данный момент:
- Генератор шаблонов под Windows, Linux.
- Клиентская библиотека под Windows, Linux с примером.
- Пример клиента, использующий эту библиотеку под Windows,Linux.
- Сайт для продвижения.
Как это выглядит?
Генератор шаблонов:
Простейший клиент (консольное приложение слева):
Как это работает?
Генератор шаблонов:
1. Создается некий шаблон, в котором графические элементы точно расположены, как на техническом чертеже.
2. Создается перечисление имен переменных
3. В нужные места шаблонов размещаются текстовые поля.
4. В текстовые поля можно вводить статичный текст вместе с именами переменных. Переменная указывается между специальными символами «${» и «}$» (пока только вручную).
5. Сохраняется шаблон в файл. В файле может быть множество шаблонов. Файлы картинок к шаблону не прикрепляются. Клиент на печать выдает только картинки в формате BMP.
Клиент + клиентская библиотека:
6. Загружает файл шаблона.
7. Выбирает шаблон (пока только через индекс).
8. Задает данные в переменные (пока только через индекс).
9. Выдает на печать. При печати могут произойти смещение из-за разных настроек полей принтера.
Заключение
Что использовалось:
- Среда разработки Code::Blocks 13.12.
- wxWidgets 3.0.2.
- MinGW 3.4.5 компилятор под Windows для проекта и компиляции wxWidgets (gcc под Linux).
- Windows 8.
- Linux Mint 17.2.
- Doxygen для формирования описания клиентской библиотеки.
- Git.
- TUT для юнит тестов.
- GDB 7.6.1 для отладки.
Что порадовало в wxWidgets:
- Плагин wxSmith в Code::Blocks помогает выполнить построение GUI в режиме графического редактора, что позволило очень сильно сократить время генерации кода.
- Пока не пришлось переписывать ни строчки кода для компиляции под Linux. Надеюсь, так будет и дальше.
- Полностью доступная подробная документация.
- Лицензия wxWidgets позволяет на основе своей библиотеки создавать приложения под все поддерживаемые платформы под различными лицензиями.
- Интернационализация приложения (GNU gettext).
- PropertyGrid из коробки.
Что не очень порадовало в wxWidgets:
- GDB при отладке не отображал, например, значение строковых классов wxString. При этом не помогли изменение конфигурации отладчика, как советуют на форумах. Грустно. Хотя в предыдущих версиях Code::Blocks у меня, кажется, эти данные отображались без исправлений. Пришлось сделать вывод строковых переменных в файл лога и смотреть в нем значения, которые записывались. Как бонус получил функционал ведения журнала действий пользователя (в релизе отключено), что тоже полезно.
- Инициализация библиотек wxWidgets происходит неявно и автоматически в макросе при использовании GUI приложения, созданном в Code::Blocks. Описание способа инициализации вручную хоть и представлены в документации и представляет собой простой вызов функции wxInitialize(), но описан крайне скудно.
Думаю, что без автоматизации многих моментов в Code::Blocks, использовать wxWidgets было бы сложнее.
Вот и все пока.
Комментарии (16)
ronme
15.12.2015 13:45-2Про кроссплатформенность. QT- я легко писал для Android (правда размер приложения был раздут. 3 кнопки на форме весили 50 Мб. Что нужно было сделать чтоб облегчить? Я не разобрался.) wxWidgets — не пробовал на Android (вроде еще не портировали)
ANtlord
15.12.2015 16:39Спасибо за статью. Несколько вопросов есть.
1) Почему выбрали модульного тестирования TUT? Можете что-нибудь сказать в сравнении с cxxtest или cppunit?
2) Почему отлаживали в gdb? В Code::Blocks насколько мне помнится есть debug.
3) Как с автодополнением в Code::Blocks? Последний раз когда его использовал, оно работало далеко не всегда для wxWidgets based проектов.ronme
15.12.2015 17:261) TUT я выбрал потому, что ничего кроме *.h файлов ему не требуется. То есть любой компилятор (с поддержкой namespace, template) способен выдавать приложение (проект юнит тестов с TUT выдает исполняемый файл), которое выполнит тесты. Для ОС типа QNX 4.25 это актуально, т.к. единственный компилятор WatcomC версии 10.6, например, не поддерживает namespace, но OpenWatcom поддерживает и способен компилировать под QNX.
Основным желанием было исключить установку дополнительных библиотек.
2) gdb единственный мне известный способ отладки программного кода, генерируемый MinGW,GCC. Debug в Code::Blocks — тип сборки приложения. В этом режиме просто компилятору добавляется опция для генерации отладочной информации, БЕЗ gdb отладить, используя MinGW и Code::Blocks не получится.
3) Автодополнение кода, действительно, иногда не отображается. Я так понял, достаточно проект целиком перепарсить (есть в Code::Blocks такая команда в Project->Reparse current Project). Чаще всего помогает, если *.h файлы нормально прописаны в поисковых путях.
orcy
15.12.2015 21:27Мне tut показался интересен еще тем в нем нет магии типа макросов (правда есть магия в виде шаблонов), т.е. используются фичи C++ для объявления тестов.
G0ran
А могли бы Вы как-то подробнее рассказать о разнице в настоящее время между wxWidgets и Qt?
ronme
Qt — один из мощнейших и популярнейших фреймворков GUI и не только. Со своими «чудесами» и чудесами.
С появлением QtQuick построение GUI стало гораздо легче чем прежде, но для тех кто столкнулся с этим первый раз (особенно если нужно лезть руками в код формы) могут быть свои трудности.
Скажем так мне до сих пор неуютно с Qt. wxWidgets по большей части позволяет создать такое же приложение. То есть по функциональному уровню их сложно отличить.
Теперь про лицензии. QT или коммерческая или GNU, wxWidgets — любая.
tzlom
Во первых пишется Qt, а QT это QuickTime
Во вторых Qt лицензируется или коммерческой лицензией или LGPL что не есть GNU в привычном понимании — ваш код распространять не требуется если вы выполняете динамическую линковку.
Gorthauer87
lgpl вполне удобна для коммерческой разработки. wxwidgets написаны косо, по аналогии с мертвым mfc, там нет никакой рефлексии и хреново с документацией. Как она может быть удобнее Qt?
Единственное что можно в оправдание сказать, что на xp новые версии уже не работают.
ronme
Спокойно, господа! Я нигде не призывал к святым войнам фанатов того или иного фреймворка.
Теперь по порядку: По поводу QT vs Qt — согласен, просто торопился исправить за 2 минуты свой комментарий. Извиняюсь.
По поводу LGPL как указано, что нет ограничений и на статик линк. При динамической линковки можете получить конфликт версий. Например, Ваше приложение написано с использованием версии1, а в версии2 уже немножко не так. Пользователь вашей программы будет «рад» неожиданным падениям и глюкам после обновления.
Про документацию wxWidgets. Только у меня получилось скачать их документацию, в формате chm, где описаны все классы и концепции, вместе с прмерами? То, что в QtCreator документация встроена, это конечно, хорошо (не знаю идет ли отдельно от Qt), мне даже нравится, как видео с презентаций или tutorial в нем отображаются, но нельзя говорить, что Qt сразу обладал качественной документацией. wxWidgets еще молод и, надеюсь, не загнется.
Про MFC. Последняя версия Visual C++ 2013. Не заметил, что он загнулся.
Gorthauer87
Про линковку и конфликт версий: я примерно понимаю в чем может быть подвох, но если целиком разрабатывать приложение и есть доступ к исходникам используемых библиотек, то проблем не будет никаких. А иначе если использовать закрытые библиотеки, то даже статическая линковка не спасет отца русской демократии.
То, что его компилируют под новые студии не означает, что он активно развивается. Да и wxWidgets как-то сто лет как новые релизы не делает и откровенно стагнирует. И молодым его не назовешь, они ровестники с Qt как бы.
ronme
Про линковку.
При динамической линковке библиотека обычно лежит в общепринятом месте, например в /lib/*, поэтому при обновлении только этой библиотеки Вы никак не влияете на совместимость. Пользователю так же придется обновить и Ваше приложение если есть сборка с поддержаной совместимостью. А если таких много? А если они требуют разные версии?
При статической линковке код библиотеки «встраивается» в Ваше приложение, поэтому все зависимости отпадают. Цена? Возросший объем приложения.
И еще раз. Такие обсуждения не конструктивны. Есть инструмент. При помощи этого инструмента, как и многие другие люди, я создал программу, и хотелось бы, критику перенести в область моей программы.
ronme
И про "… оправдание..." поясните.
Gorthauer87
Qt в какой-то версии, то ли 5.1 то ли 5.3, просто дропнули поддержку XP, то есть оно может собирается, может работает, но это точно никто не проверяет.
vladon
Оно работает, никто не дропнул. Дропать будут с Qt 5.7.
Я знаю, о чём говорю, у меня приложение на тысячи клиентов в т.ч. под XP.
vladon
На XP работает последний релиз Qt 5.5.1 и будет работать будущий Qt 5.6.
Отказ от поддержки XP планируется с Qt 5.7.
tangro
Я бы сказал, что wxWidgets поменьше и более цельная штука. Если программа планируется небольшая и надо чисто гуй без наворотов — в wxWidgets можно въехать за пол-дня и к завтрашнему вечеру уже выдать пару диалогов или визард. Qt гораздо мощнее, но и въезжать в него требуется подольше — так или иначе надо будет смотреть на moc, Qt Creator, QML, классы для невизуальных вещей. В Qt можно разбираться неделями — и всё-равно быть далёко от его полного понимания. Но и наворотить потом можно намного более навороченные вещи.