Каков предпочтительный метод создания приложения wxWidget: с помощью инструмента с графическим интерфейсом или процедурно в коде?
Я использую wxWidgets для создания инструментов тестирования на работе. Я всегда создавал графический интерфейс, создавая виджеты в коде. Я не пробовал ни один из доступных инструментов, которые помогут сделать это. Как другие пользователи wxWidgets обычно создают свой интерфейс? Если вы используете инструмент, какой инструмент вы используете? Если вы используете инструмент, какие преимущества и недостатки, по вашему мнению, существуют для использования этого инструмента?
4 ответа
Я использовал wxFormBuilder по двум причинам:
- Это кроссплатформенный, и мне нужно что-то, что будет работать на Linux.
- Я новичок в wxWidgets, и я не хотел тратить много времени на изучение GUI.
Я думаю, что это работает довольно хорошо, и, будучи знакомым с подобными инструментами построения GUI (Borland C++ Builder, Jigloo for Java, Delphi), я нашел его простым в использовании.
Если вы придерживаетесь парадигмы использования wxFormBuilder для генерации базовых классов, а затем создаете класс, который наследует для наслоения логики, специфичной для вашего приложения, абсолютно не редактируя вручную код C++, который генерирует wxFormBuilder, то это работает хорошо, и вы можете легко обновите и измените свой графический интерфейс в wxFormBuilder снова (и снова...).
Преимущества:
- Может генерировать ваши базовые графические интерфейсы довольно быстро, визуально, без необходимости постоянно просматривать документацию.
- Не нужно делать столько циклов кода / компиляции / запуска, чтобы убедиться, что ваш графический интерфейс выглядит так, как вы ожидали.
- Парадигма базового класса / производного класса может обеспечить разумное разделение вашего графического интерфейса и кода бизнес-логики.
Потенциальные недостатки
- Отказ от ответственности: я использовал wxWidgets только для создания очень простых и понятных графических интерфейсов, поэтому на самом деле не ограничивал инструмент.
- Потенциально парадигма базового класса / производного класса может иногда мешать вам, если вы делаете что-то слишком сложное с вашим GUI (OTOH, что может указывать на то, что вам, возможно, придется пересмотреть свой подход).
- У меня была ситуация, когда мне нужно было пункт меню при компиляции для одной операционной системы, но не при компиляции для другой. В wxFormBuilder нет логики для поддержки этого. Я закончил тем, что использовал короткий путь создания пункта меню, а затем мой производный класс сделал его невидимым, если это была неправильная ОС (не идеальная).
Вот и все, я думаю.
Что я нахожу, так это то, что я часто строю первый вырез в графическом интерфейсе с помощью инструмента, и когда он кажется сходящимся в "окончательной" форме, я начинаю перекодировать / реорганизовывать вручную.
Отчасти это зависит и от инструментов. Я не большой поклонник wxWidget.
Возможно, вы захотите изучить использование файлов XRC/XRS.
Хотя должен признать, что сам не удосужился сделать это. Просто генерация статического кода GUI с использованием wxFormBuilder (который поддерживает XRC, кстати) была достаточной для всех моих (небольших) проектов GUI.
Вы знаете, это зависит Например, если мне нужно стандартное поведение, я обычно использую DialogBlocks для GUI, потому что это самый быстрый способ. Если мне нужно пользовательское поведение (например, мой текущий проект - кроссплатформенный медиа-менеджер, графический интерфейс которого поддерживает скины), тогда я делаю все связанные с GUI вещи в коде. Что касается пользовательских элементов управления:
- Если элемент управления выполняет какую-то специфическую для проекта вещь, я создаю его в DialogBlocks, используя тот же файл проекта (с другими формами и диалогами, используемыми в этом проекте)
- Если мой элемент управления можно использовать повторно (элемент общего назначения), я создаю для него отдельный проект и создаю келетон в DialogBlocks - добавляю пустые обработчики событий и переменные класса, если это возможно, затем пишу логику вручную в Visual Studio.
Это оно:)