Есть два основных подохда к визуальному проектированию ГУИ.

1. ГУИ-дизайнер встраивается в IDE и генерирует код создания виджетов (контролов, etc) в конструкторе или где-то ещё (я про суть) в коде. Подобный код вы могли бы написать и вручную (хотя ручной обычно выглядит красивей   ). Яркие примеры: большинство явовских ГУИ-дизайнеров (все мне известные), VS + WinForms.

2. ГУИ-дизайнер позволяет сохранить формочки (окошки, диалоги, etc.) в некотором формате. ГУИ-либа включает средства для загрузки интерфейса из этого формата и пр. Яркие примеры: VCL, XAML-дизайнеры.

Qt Designer, например, предоставляет оба подхода, первый правда не очень удобным способом (его удобность/неудобность сейчас не обсуждаем   ).

Интересно (и вообщем то нужно) - какой подход ближе и приятней вашей программерской душе, замечу именно приятней (возможно, вы юзаете другой - из-за вашей IDE или либы). Криков - "пишите ручками" прошу не надо. Я ничего против не имею, но сейчас не про это.

Очень хотелось бы услышать обоснование вашего мнения.

Я понимаю, что большинству в принципе всё равно, но однако, если бы был выбор - что бы вы предпочли?

Отдельные (XML) файлы в ресурсах. Поддаётся анализу в отличии от кода (код сложней). Сама идеология указывать "что нужно получить на экране" более здравая чем "ставь это/делай это". Есть место для оптимизаций, т.к. гуй движок уже сам решает как собрать окошки и как не пересобирать их заново. ИМХО 

У VS2005 нравится вариант: формдизайнер генерирует код.

nerezus, это вариант 1. Однако с WPF (как я понял) будет практиковаться другой подход (что в принципе, если посмотреть на XAML формат - логично).

Типичный плюс варианта 1 - более простой биндинг с ГУИ-виджетами.

Типичный плюс варианта 2 - гораздо более продвинутые возможности по отделению интерфейса от функционала.

Если бы подвязывать обработчики событий можно было каким-то другим способом (не по строковому имени метода), то я за вариант с отдельным описанием. WPF Expression Blend доказал, что чел-дизайнер может разрабатывать GUI до того, как программер начнёт наполнять его содержанием.

А кто что о libglade скажет?

А как именно?


Моё мнение - неплохая вещь, жаль одно - гтк-ориентирована (причём онли гтк). Я (теперь уже) принципиально не против гтк, однако хотелось бы, чтобы кто-нибудь собрался и разработал единый стандарт для описания интерфейса. Чтобы большинство гуи-либ его поддерживали. Сейчас таких форматов куча: Qt *.ui, Glade XML, ASL Adam and Eve, XAML, Luxor (XUL) и многие другие, менее значительные.  Да в конце концов даже Borland *.dfm и Windows Dialog Resources.

Главное неудобство разделения, как я уже говорил - биндинг. Причём по-моему не только ивент-хандлеров (как бы они не называдись), но самих данных. Если нам надо даже тупо ввести вариант: чёрно-белый или цветной, можно придумать несколько способов:
1. Список: ч/б или цв.
2. Список: Цв.: да или нет.
3. Флажок.
4. и т. д.

По-хорошему, сие решает дизайнер. Как сделать (с добством для дизайнера) отсылку данных, фидбэк так сказать - тяжело сказать. Из того, что я нормально (ну... более-менее) смотрел - понравилась реализация в ASL. Но там сам формат ИМХО просто ужасный. Всё таки XML рулит  

А вот фиг знает как, но чтоб не по имени     

Остальное - более менее фиолетово, везде одинаково то есть. Самый универсальный способ - сериализация ГУИ в исходный код, то есть с кодогенерацией. А почему ? А потому, что:

1) если я напишу супер-пупер дизайнер, который делает кодогенерацию для дотнетовской формочки (не знаю про другие платформы), то на выходе у меня будет мега-функция, создающая форму хоть прямо в коде хоть подчитывая XML со стороны
2) если Вася Пупкин решит что его мега-дизайнер круче, то ничто не помешает ему дизайнить формочку, созданную моим мега-дизайнером, потому что эта формочка создаётся в рантайме и существует в виде класса в данном фреймворке, который можно дизайнить простым способом - добавляя, удаляя, изменяя и настраивая объекты
3) если после того как Вася Пупкин даст Феде Рюмкину мега-форму на растерзание, и федя решит что в форме не хватает полупрозрачного бордера, то федя смело может заюзать свой гипер-дизайнер с фреймворком прозрачных бордеров, т.к. форма создаётся в рантайме и может быть добавлена в другую форму, поддерживающую прозрачный бордер, и так далее

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

З.Ы. и это несмотря на вышесказанное об Expression Blend     

Если рассматривать эти 2 подхода в рамках Qt и C++, то я за первый вариант.

Разделение дизайна и кода от этого не хромает, от XML всё равно никуда не уходим: uic прекрасно делает свою работу. Сгенерированный код в правке и анализе не нуждается. Если кого - то смущает такая нагромождённость, то этот код можно просто классифицировать как дополнительный мусор наравне с ресурсами и метаобъектными файлами.

Говоря о плюсах первого подхода:
1. Более тесная работа с виджетами. Получать объект по его строковому имени - не в моём духе.
2. Automatic Connections.
3. Без лишней писанины получаем чёткий, готовый класс который можно наследовать, либо агрегировать.
4. Нет необходимости тащить с собой XML парсер
5. Оптимизация на уровне компилятора.

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

это всё ИМХО.

И всего-то?  

1) Возможность создания гуя дизайнером(человек имеется ввиду)
2) Создание универсальных средств для рисования гуя
3) Независимость от языка
4) MVC

В Qt в первом подходе это есть. Разница в том, что XML используется как промежуточный формат. Т.е. QtDesidner формирует XML, а uic компилирует его в C++ код.


 с учётом вышесказанного это есть и в первом подходе.


не понял о чём ты..

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

А я этого и хочу!   С потолка не получится - пусть разработчики основных гуи-либ соберутся и договорятся. Минимум: Qt, GTK, Swing и дотнетовское гуи (как его правильно обозвать?).


Это минус и MVC не пахнет. Мы вообще не должны работать с виджетами. Только с абстрактными данными (моделями) с одной стороны и некоторыми событиями с другой, получаемые через всякие контроллеры (ивент-провайдеры).


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


Если смотреть на дотнет и яву, то вопрос вообще отпадает. На плюсы впрочем тоже. Не минус. XML везде и всегда. Аминь.


Не факт. Вполне возможно, что рантайм-загрузку можно оптимизировать гораздо круче. Будет оптимизация на уровне дизайнера и гуи-либы.


Возможность то есть, да она всегда есть. Даже скажем дизайнер VS для WinForms. Что ж пусть дизайнер рисует, как нарисует придём мы код писать. С uic имеем на самом деле тоже. Дизайнер решил немного изменить дизайн. Скажем вместо флажка поставить список да/нет (мож красивей смотрится). Отлично - переписыаем код. Если бы была привзяка данных к модели, было бы гораздо лучше.


С учётом вышесказанного нету.   


Вообще говоря - плохо они отделяют. Привязка в обоих к коду жуткая. Хотелось бы реализацию (настоящую реализацию, а не мнимую) MVC на уровне ГУИ-фреймворков. Единственная попытка мне известная - у адобы. Они вообще похоже во всей ASL стремятся к красивому грамотному проектированию. Но либа ИМХО ужасная. Ничго серьёзного у меня с ней сотворить не получилось (я именно про гуй) :(

mr.DUDA, иди я что-то туплю или что - не знаю, но про твою историю из будней дизайнеров не понял.   

И ещё один минус первого варианта (чисто субъективный). Раз уж код генерится - хочется чтобы он был кодом, а не мусором (потому не люблю я скажем и YACC - спирит в 10 раз приятней). С хорошей либой (Qt, Swing) обычно руками немногим дольше получается написать - плюс приятно смотреть (для меня это важно - не пинать). С WinForms не пробовал, так как... не пробовал. Строго говоря, про свинг говорю, просто представляя сие. Нормально только с кутехой работал. Всмысле проекты серьёзные (боль-менее) были.

Любитель, полностью согласен. Действительно вместо собирания окошек с точным заданием виджетов лучше описывать что ты хочешь показать (список, текст, DOM дерево (форматированный текст) и т.д.). Дизайнер затем может связать это на свой вкус. Плюсы в следующем:

• простая поддержка шкурок, твой код проще, т.к. и не догадывается о шкурках
• простые хоткеи, без гимморный биндинг на разных платформах (win, mac), снова твой код даже не догадывается об этом
• простая реализация accessibility, без гимморный вывод на специальные устройства, снова это всё не в логике твоего кода

Другими словами логика становиться проще, мы просто получаем события. Событий правда много, для того же списка можно придумать "option-selected(selected-options)", "option-pointed(options)", "option-tooltip", "option-help" и так далее. Целые классы событий нужно продумать и оставить это всё расширяемым. Это большая работа для архитектора GUI либы 

Енто, без сомнения, вообще пишет дизайнер (ну или кто-то ещё- не программер). Да и вообще я бы хотел, чтобы программер предоставлял список экшенов, которые меняют данные модели или иным образом общаются с гуем. Теперь дизайнер коннектит события к этим экшенам как хочет. А всякие банальные эфекты, тултипы и прочие тривиальные вещи вообще конектит в стиле многочисленных автоплей-креаторов или паувер-поинтов