Графический интерфейс Handcode или использовать инструмент gui-designer

Я хотел бы услышать некоторые мнения о том, как кодировать ваши графические интерфейсы, как это обычно бывает при использовании Java или Qt с С++, и с помощью инструмента gui-designer? Примерами инструментов GUI-дизайнера могут быть MFC GUI-дизайнер, Qt-дизайнер, Interface Builder (Apple).

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

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

Использование инструмента GUI-дизайнера заставляет значительно более четкое разделение между внешним видом и логикой на мой взгляд.

ОТВЕТЫ

Ответ 1

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

Конструктор Qt получил эту функцию, чтобы создать класс из .ui файла 1), но я думаю, что не использовать эту функцию - лучший способ, поскольку это создает только более закодированное, что не должно существовать вообще. Ошибка при создании окна из файла .ui незначительна, поскольку окно нужно загружать только один раз.

Это PyQt, но что-то подобное возможно в С++:

class SelectDateDialog(QDialog):
    def __init__(self):
        QDialog.__init__(self)
        uic.loadUi("resources/SelectDate.ui", self)

По существу это имеет тот же эффект, что и весь ваш UI-код в метод __init__(), но пользовательский интерфейс почти полностью отделен от кода.

1).ui файлы - это файлы XML, описывающие пользовательский интерфейс

Ответ 2

Я бы всегда вручную нарисовал дизайн графического интерфейса, где нет стандартного (или де-факто стандартного) языка разметки GUI (как с Java). Причина этого заключается в том, что я обнаружил, что в инструменте проектирования GUI-Builder вы привяжете вас к использованию конкретной среды разработки. Со временем лучшая IDE для дизайна графического интерфейса и/или кода написания будет изменяться, и каждый разработчик должен иметь право выбирать, какую IDE они чувствуют наиболее комфортно.

Где я работаю в данный момент, у нас есть много графических интерфейсов, которые были написаны с помощью Netbeans Matisse Создатель GUI (по моему совету в то время:-). Теперь они почти не поддаются контролю, потому что все разработчики предпочитают IntelliJ IDEA или Eclipse в качестве их IDE. Это не реалистично или не работает, если разработчики запускают Netbeans только для изменения макета GUI (люди не сохраняют определения проекта Netbeans в синхронизации и т.д.).

Еще один момент заключается в том, что общее время, выписывающее код макета GUI, вероятно, составляет всего 5% от общего объема усилий по разработке данного проекта. Даже если вам потребуется в два раза больше времени, чтобы написать код самостоятельно, это не переводит столько накладных расходов на грандиозную схему вещей. И это небольшая цена за долгосрочную ремонтопригодность.

До тех пор, пока вы не знаете, как отделить логику макета GUI от бизнес-логики, я не верю, что в результате чего-то пострадает. Здесь никто не использует GUI-сборщики!

Ответ 3

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

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

Поиск правильного элемента в большой панели может быть затруднительным.

?? Я никогда не видел этого.

Ответ 4

Забавно, что для меня это было наоборот. Говоря с точки зрения Winforms, код, созданный дизайнером, довольно шумный, возможно, четверть или половина всех параметров свойств действительно необходимы. Создание довольно больших элементов управления также является скорее соблазном при работе с дизайнером. Изменение некоторой иерархии элементов управления в дизайнере Winforms - это совершенно кошмар в моих глазах.

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

Я также стараюсь больше полагаться на функции автоматического компоновки, которые, по общему признанию, намного приятнее в WPF, но также могут пойти каким-то образом в Windows Forms.

Ответ 5

Я бы настоятельно советовал вам использовать Interface Builder для OS X. Выполнение этого вручную отлично, если вы хотите учиться, но вы собираетесь сэкономить много головных болей, используя его в реальных проектах. Это действительно достаточно мощно.

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

Ответ 6

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

Всегда есть вещи, которые не может сделать GUI-конструктор (например, установка цвета в константу UIColor в Interface Builder). С другой стороны, большая часть работы пользовательского интерфейса довольно мирская (например, добавление статических меток).

Я предпочитаю делать мирские вещи в построителе GUI и более интересные вещи в коде.

Кроме того, я иногда могу вручную редактировать XML, созданный конструктором GUI (Interface Builder и поляну в моем случае).

Ответ 7

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

Возьмите, например, диалог настроек Eclipse или OpenOffice. Есть множество категорий и множество разных опций для каждого. Если вам нужно сделать что-то такого размера, рука, создающая каждый экран, является мирской задачей. Гораздо лучший подход - написать код, который будет генерировать элементы пользовательского интерфейса "на лету" из предоставленных данных домена в соответствии с некоторыми соглашениями и значениями по умолчанию.

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

И, наконец, если вы используете Java, обязательно посмотрите MigLayout. Он работает с Swing и SWT, его синтаксис очень краток и ясен, и он имеет режим отладки, который невероятно полезен.

Ответ 8

Я склонен думать, что правильный ответ зависит от культуры целевой платформы. В OS X Interface Builder является такой неотъемлемой частью цепочки инструментов, что ее трудно избежать.

В Java (awt или swing) обратное действительно верно. Для этого нет поддержки инструментальной привязки.

Действительно, способ, которым вы можете сказать, - это то, как инструменты производят свои результаты. Интерфейс Builder создает файлы формата .nib, которые специфичны для способа Cocoa помещает элементы управления на экран. Он понимает, что является по существу форматом разметки интерфейса. У Java нет такой подобной концепции. Все это скомпилированный класс, и поэтому его гораздо труднее получить удобные результаты.

GTK +, в сочетании с поляной, похоже, имеет разумный баланс между ними.

Ответ 9

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

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

Ответ 10

Мой взгляд на это: 1. Кодированный GUI-код с ручной кодировкой гораздо более многоразовый 2. Проблемы с компоновкой проще с дизайнерами.

Ответ 11

Ручное кодирование может быть хорошим, если вы хотите использовать некоторые нестандартные функции, включенные в пользовательский интерфейс. У вас больше гибкости, но вам нужно потратить больше времени на создание хорошего интерфейса, потому что Java/С++ - это язык, который не предназначен для настройки дизайна пользовательского интерфейса.

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

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

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

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

Возможно, в будущем дизайнеры будут более мощными, или, возможно, появятся новые языки, специализированные в дизайне интерфейса, которые будут более подходящими для использования в С++/Java, что-то вроде XUL или XAML.