GUI GUI или использовать инструмент gui-designer

Question

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

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

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

Answer 4

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

Answer 5

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

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

Answer 6

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

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

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

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

Answer 7

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

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

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

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

Answer 8

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

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

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

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

Answer 9

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

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

Answer 10

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

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

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

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

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

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

Answer 11

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

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

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

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