Ручной кодированный GUI по сравнению со спокойным разработчиком [закрытый] GUI

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

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

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

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

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

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

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

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

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

Однако я хотел бы упомянуть потенциальную проблему с использованием спокойного Разработчика там. Случай реального мира: потребовалось несколько секунд (скажите 10) загрузить сложное диалоговое окно Java (диалоговое окно Preferences для текстового редактора программиста) с большим количеством опций. Корректная фиксация должна была бы загрузить каждую из вкладок только, когда программист хотел видеть их (я понял что после), путем добавления отдельного метода для каждого предпочтительного набора для создания его GUI.

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

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

Это - частично вопрос стиля и куда Вы происходите из: когда я запустил на QT, я имел ужасные события DreamWeaver и Первой полосы и других визуальных инструментов HTML, и далеко предпочел писать код с HomeSite и обращаться к Photoshop для хитрых проблем расположения.

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

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

Удача с QT - это - большой инструментарий, однако Вы используете его, и спокойный Создатель похож на то, чтобы быть большим IDE.

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

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

Мой собственный опыт, который возвращается приблизительно 4 года, с помощью Qt3.3, состоит в том, что динамическое поведение в диалоговых окнах не было возможно понять в Разработчике.

По моему опыту, со спокойным Разработчиком и другим toolkits/UI-tools:

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

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

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

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

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