Qt Designer vs Handcoding

Question

Каждый раз, когда я запускаю проект с использованием некоторого графического инструментария, возникает один из первых конфликтов с решением о том, как работать с визуальным дизайном и макетом виджета: графический инструмент или кодирование?довольно сложный / субъективный вопрос, потому что большинство людей будут решать исходя из личных предпочтений.Это также сильно зависит от качества графического инструмента.В этом случае я хотел бы сосредоточиться только на последней версии библиотеки QT.Я не собираюсь обсуждать, какой метод лучше.Я убежден, что лучший ответ: зависит от проекта.

То, что я хочу, - это ссылка на хорошую непредвзятую статью, основанную на опыте после нескольких проектов.Статья должна просто описать компромиссы обоих вариантов

Answer 1

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

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

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

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

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

Разное

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

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

Answer 2

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

Qt Designer

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

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

• Хорошо

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

• Bad

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

Советы

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

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

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

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

Answer 3

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

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

Answer 4

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

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

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

Answer 5

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

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

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

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

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

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

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