Qt Designer vs Handcoding

Ответ 1

Я начал с выполнения всего ручного кодирования и в последнее время переключился на использование Qt Designer для большинства форм. Вот некоторые преимущества для каждой позиции:

Использование Qt Designer

• Самая большая экономия времени для меня - управление сложными макетами; это экономит много утомительного кодирования. Просто (очень грубо) расположите свои виджеты, выберите их, щелкните правой кнопкой мыши и поместите их в правильный тип макета. Тем более, что макеты становятся вложенными, это намного проще.
• Как правило, ваши файлы реализации становятся чистыми, а не заполняют их всем кодом шаблона. Я типа-A, поэтому мне это нравится.
• Если вы переводите свое приложение, вы можете отправить переводчикам файлы .ui, чтобы они могли видеть в вашем графическом интерфейсе, где текст, который они переводит, будет. (Предполагая, что они используют Qt Linguist.)

Ручной кодирования

• Control. Если у вас есть макет, где вам нужно создавать/инициализировать элементы управления в определенном порядке или динамически создавать элементы управления на основе других критериев (поиск базы данных и т.д.), Это самый простой способ.
• Если у вас есть пользовательские виджеты, вы можете сортировать использование конструктора, добавляя ближайший встроенный QWidget, из которого ваш класс был получен, а затем "обновляя" его. Но вы не увидите предварительный просмотр своего виджета, если вы не сделаете его плагином дизайнера в отдельном проекте, что слишком много для большинства случаев использования.
• Если у вас есть пользовательские виджеты, которые принимают параметры в своем конструкторе за пределами дополнительного родителя QWidget, конструктор не может его обработать. У вас нет выбора, кроме как добавить этот элемент управления вручную.

Разное

• Я не использую функцию автосоединения SLOTS и SIGNALS (на основе соглашения об именах, такого как "on_my_button_clicked".) Я обнаружил, что я почти всегда должен устанавливать это соединение в определенное время, а не когда Qt это для меня.
• Для форм QWizard я обнаружил, что мне нужно использовать другой файл пользовательского интерфейса для каждой страницы. Вы можете сделать все это в одном, но становится очень неудобно общаться между страницами любым способом.

В заключение, я начинаю с Qt Designer и позволяю ему взять меня, насколько это возможно, а затем вручную откорректировать его. Это одна хорошая вещь о том, что генерирует Qt Designer - это просто еще один класс, который становится членом вашего класса, и вы можете получить к нему доступ и управлять им по мере необходимости.

Ответ 2

Мой ответ основан на двухлетнем развитии приложений для биохимии с использованием PyQt4 (привязки Python к Qt 4) и OpenGL. Я не делал С++ Qt, потому что мы использовали только С++ для критически важных алгоритмов. Тем не менее, API PyQt4 очень похож на Qt4, так много здесь все еще применяется.

Qt Designer

• Хорошо
  • Exploration. Узнайте, какие виджеты доступны, имена для этих виджетов, какие свойства вы можете установить для каждого и т.д.
  • Обеспечивает разделение логики пользовательского интерфейса от логики приложения.
• Bad
  • Если вам нужно добавить или удалить виджеты во время выполнения, вы должны иметь эту логику в коде. Я думаю, что это плохая идея поместить вашу логику пользовательского интерфейса в два места.
  • Внесение изменений в вложенные макеты. Когда в макете нет виджета, он обрушивается, и очень трудно перетащить виджет в нужное место.

Ручное кодирование

• Хорошо

  • Быстро, если вы хорошо знакомы с Qt.
  • Лучший выбор, если вам нужно добавить или удалить виджеты во время выполнения.
  • Легче, чем Qt Designer, если у вас есть собственные пользовательские виджеты.
  • С помощью дисциплины вы по-прежнему можете отделять макет интерфейса от поведения. Просто поставьте свой код для создания и компоновки виджетов в одном месте, а ваш код - для установки сигналов и слотов в другом месте.

• Bad

  • Медленно, если вы новичок в Qt.
  • Не принудительно разделение макета из поведения.

Советы

• Не переходите к созданию своих окон. Начните с быстрого рисования нескольких возможных конструкций либо на бумаге, либо с помощью инструмента, такого как Balsamiq Mockups. Хотя вы можете сделать это в Qt Designer, я думаю, что слишком заманчиво тратить много времени, пытаясь заставить ваши окна выглядеть прямо перед тем, как вы даже решили, что это лучший дизайн.

• Если вы используете Qt Designer для PyQt, у вас есть дополнительный шаг для запуска pyuic4 для компиляции ваших файлов *.ui в исходные файлы Python. Мне было легко забыть этот шаг и поцарапать голову на секунду, почему мои изменения не сработали.

• Если вы кодируете свой интерфейс вручную, я предлагаю разместить ваш код макета в одном месте, а ваши сигналы и слоты в другом месте. Это упрощает изменение способа расположения ваших виджетов в окне, не затрагивая ни одну из ваших прикладных логик. Или вы можете изменить какое-либо поведение, не пропустив весь код макета.

Наслаждайтесь Qt! Теперь, когда я использую Java Swing для работы, я скучаю по нему.

Ответ 3

Я склонен к диалогам макетов с помощью конструктора, но я делаю все материалы обработки событий в основном коде. Я также делаю все основные окна, панели инструментов, меню в прямом коде.

Дизайнер просто разочаровывает - жаль, поскольку достойные дизайнеры, основанные на растягивании и растягивании, уже более десяти лет работают

Ответ 4

Я использую комбинацию обоих:

• Я нахожусь для координат x, y, конструктор - это путь.

• В вашем коде могут быть установлены многие другие свойства пользовательского интерфейса и т.д.

Я думаю, что попытка полностью выполнить пользовательский интерфейс с помощью ручного кодирования будет очень трудоемким проектом. Это не так просто, как настройка таблиц HTML.

Да, версия 4 плохая, но люди на работе, которые использовали версию 3, сказали, что это ДЕЙСТВИТЕЛЬНО плохо. Много сбоев.

Я, вместе со своими коллегами QTers, действительно надеюсь, что версия 5 станет улучшением.

Я знаю, что это старый вопрос, но я надеюсь, что это поможет! Опыт одного человека.

Ответ 5

Это зависит от количества различных окон/панелей, которые вам нужны для вашего приложения. Если число мало, используйте графический инструмент. Гораздо быстрее получить несколько окон, разработанных отлично. Если число велико, графический инструмент может (и должен) использоваться только для прототипов. Вам нужно закодировать макет, чтобы иметь возможность делать изменения в приложении по приемлемой цене.

Это включает в себя создание модели того, как работает пользовательский интерфейс приложения, а также динамическое добавление и удаление виджетов во время выполнения. Для превосходного примера такой модели (в другой среде) взгляните на гламурную модель для создания объектных браузеров.

Я возражаю против предположения, что это сложно или субъективно (по крайней мере, больше, чем другие варианты развития). Легко придумать критерии для принятия решения. Для этого важны личный опыт и предпочтения, поскольку они решают, когда количество различных окон должно считаться небольшим. То же самое касается качества инструмента.