Графический интерфейс с ручным кодированием по сравнению с графическим интерфейсом Qt Designer [закрыто]

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

Я, например, обнаружил, что написание кода вручную было концептуально проще, чем использование Qt Designer, хотя для сложных GUI Designer может иметь смысл. Большие графические интерфейсы могут быть возможны с помощью Designer, но со временем им может стать очень трудно управлять по мере увеличения сложности (это только мое мнение). Я также загрузил исходный код AmaroK, чтобы взглянуть на то, что делают эти ребята, и обнаружил много вызовов addWidget () и друзей, но ни один из этих XML-файлов, созданных Designer (кроме того: AmaroK должен быть моим любимым приложением когда-либо любая платформа).

Что же тогда является «правильным» способом создания графического интерфейса пользователя? Дизайнер или код? Давайте для этого обсуждения рассмотрим следующие типы графических интерфейсов пользователя:

1. Простые диалоги, которые просто нужно ввести, показать результат и выйти. Предположим, что приложение принимает URL-адрес YouTube и загружает видео на жесткий диск пользователя. Типы приложений, с которыми может начать новичок.
2. Графические интерфейсы среднего уровня, такие как, скажем, редактор заметок с несколькими элементами панели инструментов / меню. Возьмем, к примеру, xPad ( http://getxpad.com/ ). Я бы сказал, что большинство приложений попадают в категорию «утилит».
3. Очень сложные графические интерфейсы, такие как AmaroK или OpenOffice. Вы узнаете их, когда видите их, потому что они вызывают кровотечение из ваших глаз.

Наш опыт работы с Designer начался в Qt3.

Qt3

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

Qt4

Qt4 значительно улучшил конструктор. Он больше не только генерирует код, но вы можете динамически загружать свои файлы конструктора (в xml) и динамически подключать их к запущенным объектам в вашей программе - однако сгенерированного кода нет, вам нужно назвать элементы в конструкторе и придерживаться с именами, чтобы не нарушить ваш код.

По моим оценкам, он далеко не так полезен, как Interface Builder в Mac OS X, но на этом этапе я мог видеть использование файлов Designer непосредственно в программе.

Мы не возвращались в Designer со времен Qt3, но по-прежнему используем его для прототипирования и отладки макетов.

Для ваших проблем:

1. Возможно, вам удастся избежать использования стандартных диалоговых окон, которые предлагает Qt. QInputDialog, или если вы создаете подкласс QDialog, обязательно используйте QButtonDialogBox, чтобы убедиться, что ваши кнопки имеют правильную компоновку платформы.

2. Вы, вероятно, могли бы сделать что-то более ограниченное, например xPad с ограниченной функциональностью Designer.

3. Я бы не подумал, что можно написать что-то вроде OpenOffice только с помощью Designer, но, возможно, дело не в этом.

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

По моему опыту работы с Qt Designer и другими инструментами / UI-инструментами:

• Инструменты пользовательского интерфейса ускоряют работу.
• Инструменты пользовательского интерфейса упрощают настройку макета позже.
• Инструменты пользовательского интерфейса упрощают / позволяют непрограммистам работать над дизайном пользовательского интерфейса.

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

Я не обнаружил, что масштаб проекта имеет значение. Ваш опыт может отличаться.

Файлы, созданные с помощью инструментов пользовательского интерфейса (я думаю, вы могли бы написать их вручную, если бы действительно захотели), часто можно динамически загружать во время выполнения (Qt и GTK + предоставляют эту функцию). Это означает, что вы можете вносить изменения в макет и тестировать их без перекомпиляции.

В конечном счете, я считаю, что эффективными могут быть как исходный код, так и инструменты пользовательского интерфейса. Вероятно, это во многом зависит от среды, инструментария / UI-инструмента и, конечно же, личных предпочтений. Мне нравятся инструменты пользовательского интерфейса, потому что они заставляют меня работать быстро и позволяют легко вносить изменения позже.

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

• Работа с Qt Designer, по крайней мере на тот момент, была нереалистичным вариантом: было слишком много функций, которые нельзя было реализовать с помощью Qt Designer;
• Условные обозначения и структура, которые необходимо было сохранить, препятствовали использованию Qt Designer;
• После того, как вы начали без Designer, вероятно, будет трудно вернуться к нему;
• однако наиболее важным аспектом было то, что программисты очень привыкли к программированию с использованием vi или emacs, а не с помощью IDE с графическим интерфейсом.

Мой собственный опыт, который восходит ок. 4 года использования Qt3.3 - это то, что динамическое поведение в диалогах не удалось реализовать в Designer.

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

Отчасти это вопрос стиля и того, откуда вы пришли: когда я начинал работать с Qt, у меня был ужасный опыт работы с Dreamweaver, Frontpage и другими визуальными инструментами HTML, и я гораздо предпочел писать код с помощью HomeSite и прибегать к Photoshop для сложной компоновки. проблемы.

В IDE с визуальным кодом есть опасность, которую вы пытаетесь уложить в визуальные инструменты, но в конечном итоге также приходится настраивать код - способами, которые не совсем понятны.

Изучая, например, разработку для iPhone, я обнаружил, что неприятно использовать «волшебные» визуальные элементы («перетащить из пустого круга в инспекторе подключений к объекту в окне Interface Builder ...»), что было бы проще (для меня) понять в простом старом коде.

Удачи с Qt - это отличный инструментарий, как бы вы его ни использовали, а Qt Creator выглядит отличной IDE.

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

С тех пор как я перешел с Delphi на Java для приложений с графическим интерфейсом (еще в 2002 году), я больше никогда не использовал дизайнеров. Мне гораздо больше нравятся менеджеры по расположению. И да, вы получаете шаблонный код, но перемещение объектов в UI-дизайнере может занять столько же времени, сколько и изменение шаблона. Кроме того, я бы застрял в медленной среде IDE; это для случая Java / C #, ОК, а для Qt (особенно Qt4) это не применимо. Для Qt3 мне интересно, почему нужно редактировать сгенерированный код - разве нельзя было добавить код в другие файлы? По какой причине?

Об обсуждаемых случаях: 1) GUI с ручным кодированием, вероятно, будет писать быстрее, по крайней мере, если вы знаете свои библиотеки. Если вы новичок и не знаете их, вы можете сэкономить время и меньше учиться с дизайнером, поскольку вам не нужно изучать API, которые вы используете. Но «учиться меньше» является ключевым фактором, поэтому в обоих случаях я бы сказал, что GUI с ручным кодированием.

2) Строки меню писать код довольно утомительно. Также подумайте о деталях, таких как ускорители и так далее. Тем не менее, это зависит от того, к чему вы привыкли. Через некоторое время, возможно, будет быстрее набрать этот шаблон, чем щелкнуть мышью в дизайнере, чтобы исправить все эти свойства, но только если вы действительно можете вводить как на пишущей машинке (например, те администраторы, для которых ввод команд Unix выполняется быстрее, чем используя любой графический интерфейс).

3) Я бы расширил ответ для случая №2 на этот. Обратите внимание, что для платформ Win32 может быть возможно, что использование конструкторов, которые генерируют ресурсы Win32, может быть быстрее для загрузки (не знаю об этом).

Однако я хотел бы упомянуть о потенциальной проблеме с использованием Qt Designer. Случай из реальной жизни: потребовалось несколько секунд (скажем, 10), чтобы загрузить сложный диалог Java (диалоговое окно «Настройки» для текстового редактора программиста) с множеством опций. Правильным исправлением было бы загружать каждую из вкладок только тогда, когда программист хотел их увидеть (я понял это после), добавляя отдельный метод к каждому набору предпочтений для создания своего графического интерфейса.

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

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

Странно, что вы говорите, что писать код проще, чем манипулировать объектами в графической среде. Это несложно.
Дизайнер призван облегчить вам жизнь и в долгосрочной перспективе сделать ваш код более удобным в сопровождении. Легче заглянуть в дизайнер, чтобы увидеть, как выглядит ваш пользовательский интерфейс, чем читать код и пытаться представить, как он может выглядеть.
С текущей версией Qt вы можете делать почти все из конструктора, а очень немногие вещи, которые вы не можете сделать, вы можете исправить с помощью очень небольшого количества строк кода в конструкторе. Возьмем, к примеру, простейший пример - добавление соединения сигнал-слот. Использовать конструктор так же просто, как двойной щелчок. Без дизайнера вам нужно найти правильную подпись сигнала, отредактировать файл .h, а затем отредактировать, напишите свой код в файле .cpp. Дизайнер позволяет вам быть выше этих деталей и сосредоточиться на том, что действительно важно - на функциональности вашего приложения.

Мне нравится сначала обращаться к дизайнеру для разработки виджетов GUI. Как упоминалось в других сообщениях, это быстрее. Вы также получаете немедленную обратную связь, чтобы увидеть, «выглядит ли она правильно» и не сбивает ли пользователя с толку. Дизайнер - главная причина, по которой я предпочитаю Qt другим инструментам. Я в основном использую дизайнер для создания одноразовых диалогов.

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

Кстати, дизайнер в Qt 4 - это не IDE, как в Qt 3. Это просто редактор для редактирования файлов .ui. Мне это нравится. Новая кроссплатформенная IDE будет называться Qt Creator.

Это старый пост, но я бы посоветовал вам взглянуть на Clementine - музыкальный проигрыватель, который (я думаю) происходит от Amarok. Они используют Qt4, и, насколько я могу судить, в папке src проекта есть папка ui . В папке ui, как и следовало ожидать, есть всевозможные файлы .ui. Если вы скомпилируете и запустите Clementine, вы увидите, что графический интерфейс довольно сложный и довольно приятный.

Для меня это зависит от того, сколько логики инкапсулировано в виджете / графическом интерфейсе. Если речь идет о простых формах, я предпочитаю использовать QtDesigner.

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

Мы используем Qt Designer, если кому-то нужно создать графический интерфейс.
Дело в том, чтобы создать небольшие виджеты для определенных задач (как если бы вы делали в дизайне классов), а затем собрать их вместе в «родительский интерфейс».

Таким образом, ваши виджеты можно многократно использовать и использовать для Guis в модульном режиме. Вам просто нужно указать, какие сигналы отправляет каждый виджет и какие слоты они предоставляют.

Мы дополнительно создаем .ui-файлы, которые могут быть созданы в процессе сборки. До сих пор не было необходимости редактировать эти файлы вручную.

Создавайте различные части вашего пользовательского интерфейса
в разных файлах .ui с помощью QtDesigner, а
затем объединяйте их (и добавляйте сложности) в код.

Есть вещи, которые вы не можете делать в Qt Designer, вы можете делать только в коде,
поэтому Qt Designer - лишь одна (отличная) часть цепочки инструментов .