Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Религиозные войны > ГУИ-дизайнеры

Автор: Любитель 5.3.2007, 22:38

Есть два основных подохда к визуальному проектированию ГУИ. 1. ГУИ-дизайнер встраивается в IDE и генерирует код создания виджетов (контролов, etc) в конструкторе или где-то ещё (я про суть) в коде. Подобный код вы могли бы написать и вручную (хотя ручной обычно выглядит красивей   ). Яркие примеры: большинство явовских ГУИ-дизайнеров (все мне известные), VS + WinForms. 2. ГУИ-дизайнер позволяет сохранить формочки (окошки, диалоги, etc.) в некотором формате. ГУИ-либа включает средства для загрузки интерфейса из этого формата и пр. Яркие примеры: VCL, XAML-дизайнеры. Qt Designer, например, предоставляет оба подхода, первый правда не очень удобным способом (его удобность/неудобность сейчас не обсуждаем   ). Интересно (и вообщем то нужно) - какой подход ближе и приятней вашей программерской душе, замечу именно приятней (возможно, вы юзаете другой - из-за вашей IDE или либы). Криков - "пишите ручками" прошу не надо. Я ничего против не имею, но сейчас не про это. Очень хотелось бы услышать обоснование вашего мнения. Я понимаю, что большинству в принципе всё равно, но однако, если бы был выбор - что бы вы предпочли?

Автор: Sardar 5.3.2007, 23:11

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

Автор: nerezus 6.3.2007, 08:03

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

Автор: Любитель 6.3.2007, 08:15

nerezus, это вариант 1. Однако с WPF (как я понял) будет практиковаться другой подход (что в принципе, если посмотреть на XAML формат - логично). Типичный плюс варианта 1 - более простой биндинг с ГУИ-виджетами. Типичный плюс варианта 2 - гораздо более продвинутые возможности по отделению интерфейса от функционала.

Автор: mr.DUDA 8.3.2007, 16:12

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

Автор: nerezus 8.3.2007, 18:03

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

Автор: Любитель 9.3.2007, 14:00

Цитата(mr.DUDA @  8.3.2007,  16:12 ) не по строковому имени метода А как именно? Цитата(nerezus @  8.3.2007,  18:03 ) А кто что о libglade скажет? Моё мнение - неплохая вещь, жаль одно - гтк-ориентирована (причём онли гтк). Я (теперь уже) принципиально не против гтк, однако хотелось бы, чтобы кто-нибудь собрался и разработал единый стандарт для описания интерфейса. Чтобы большинство гуи-либ его поддерживали. Сейчас таких форматов куча: Qt *.ui, Glade XML, ASL Adam and Eve, XAML, Luxor (XUL) и многие другие, менее значительные.  Да в конце концов даже Borland *.dfm и Windows Dialog Resources. Главное неудобство разделения, как я уже говорил - биндинг. Причём по-моему не только ивент-хандлеров (как бы они не называдись), но самих данных. Если нам надо даже тупо ввести вариант: чёрно-белый или цветной, можно придумать несколько способов: 1. Список: ч/б или цв. 2. Список: Цв.: да или нет. 3. Флажок. 4. и т. д. По-хорошему, сие решает дизайнер. Как сделать (с добством для дизайнера) отсылку данных, фидбэк так сказать - тяжело сказать. Из того, что я нормально (ну... более-менее) смотрел - понравилась реализация в ASL. Но там сам формат ИМХО просто ужасный. Всё таки XML рулит

Автор: mr.DUDA 9.3.2007, 23:38

Цитата(Любитель @  9.3.2007,  13:00 ) А как именно? А вот фиг знает как, но чтоб не по имени      Остальное - более менее фиолетово, везде одинаково то есть. Самый универсальный способ - сериализация ГУИ в исходный код, то есть с кодогенерацией. А почему ? А потому, что: 1) если я напишу супер-пупер дизайнер, который делает кодогенерацию для дотнетовской формочки (не знаю про другие платформы), то на выходе у меня будет мега-функция, создающая форму хоть прямо в коде хоть подчитывая XML со стороны 2) если Вася Пупкин решит что его мега-дизайнер круче, то ничто не помешает ему дизайнить формочку, созданную моим мега-дизайнером, потому что эта формочка создаётся в рантайме и существует в виде класса в данном фреймворке, который можно дизайнить простым способом - добавляя, удаляя, изменяя и настраивая объекты 3) если после того как Вася Пупкин даст Феде Рюмкину мега-форму на растерзание, и федя решит что в форме не хватает полупрозрачного бордера, то федя смело может заюзать свой гипер-дизайнер с фреймворком прозрачных бордеров, т.к. форма создаётся в рантайме и может быть добавлена в другую форму, поддерживающую прозрачный бордер, и так далее Это, конечно, идеальный случай. Здесь я не рассматриваю скользкий случай наследования декларативно описываемых контролов и вложенных коллекций контролов, который в дотнете был реализован кривыми руками. Но в целом - за кодогенерацию, т.к. расширяемость и наследуемость в отрыве от исходников достаточно проблематично организуется. З.Ы. и это несмотря на вышесказанное об Expression Blend

Автор: S.A.P. 10.3.2007, 00:55

Если рассматривать эти 2 подхода в рамках Qt и C++, то я за первый вариант. Разделение дизайна и кода от этого не хромает, от XML всё равно никуда не уходим: uic прекрасно делает свою работу. Сгенерированный код в правке и анализе не нуждается. Если кого - то смущает такая нагромождённость, то этот код можно просто классифицировать как дополнительный мусор наравне с ресурсами и метаобъектными файлами. Говоря о плюсах первого подхода: 1. Более тесная работа с виджетами. Получать объект по его строковому имени - не в моём духе. 2. Automatic Connections. 3. Без лишней писанины получаем чёткий, готовый класс который можно наследовать, либо агрегировать. 4. Нет необходимости тащить с собой XML парсер 5. Оптимизация на уровне компилятора. Из достоинств второго подхода могу отметить только возможность править GUI без перекомпиляции... это всё ИМХО.

Автор: nerezus 10.3.2007, 08:59

Цитата Из достоинств второго подхода могу отметить только возможность править GUI без перекомпиляции... И всего-то?   1) Возможность создания гуя дизайнером(человек имеется ввиду) 2) Создание универсальных средств для рисования гуя 3) Независимость от языка 4) MVC

Автор: S.A.P. 10.3.2007, 09:52

Цитата(nerezus @  10.3.2007,  08:59 ) Возможность создания гуя дизайнером(человек имеется ввиду) В Qt в первом подходе это есть. Разница в том, что XML используется как промежуточный формат. Т.е. QtDesidner формирует XML, а uic компилирует его в C++ код. Цитата(nerezus @  10.3.2007,  08:59 ) Независимость от языка Цитата(nerezus @  10.3.2007,  08:59 ) MVC   с учётом вышесказанного это есть и в первом подходе. Цитата(nerezus @  10.3.2007,  08:59 ) Создание универсальных средств для рисования гуя не понял о чём ты..

Автор: mr.DUDA 10.3.2007, 13:49

Цитата(nerezus @  10.3.2007,  07:59 ) Создание универсальных средств для рисования гуя Тоже не понял. ИМХО, ты путаешь, нельзя же дизайнить libglade и XAML одним универсальным средством рисования, раз оба отделяют код от дизайна. Специфика везде своя, достичь универсальности одним разделением на XML и код невозможно.

Автор: Любитель 10.3.2007, 23:49

Цитата(mr.DUDA @  10.3.2007,  13:49 ) Специфика везде своя, достичь универсальности одним разделением на XML и код невозможно А я этого и хочу!   С потолка не получится - пусть разработчики основных гуи-либ соберутся и договорятся. Минимум: Qt, GTK, Swing и дотнетовское гуи (как его правильно обозвать?). Цитата(S.A.P. @  10.3.2007,  00:55 ) Более тесная работа с виджетами. Это минус и MVC не пахнет. Мы вообще не должны работать с виджетами. Только с абстрактными данными (моделями) с одной стороны и некоторыми событиями с другой, получаемые через всякие контроллеры (ивент-провайдеры). Цитата(S.A.P. @  10.3.2007,  00:55 ) Automatic Connections Вообще не понравилось. Ещё больший минус - привязка дизайна (имена виджетов ведь получается задаёт дизайнер) и конкретных сигналов к именам методов - бред. Цитата(S.A.P. @  10.3.2007,  00:55 ) Нет необходимости тащить с собой XML парсер Если смотреть на дотнет и яву, то вопрос вообще отпадает. На плюсы впрочем тоже. Не минус. XML везде и всегда. Аминь. Цитата(S.A.P. @  10.3.2007,  00:55 ) Оптимизация на уровне компилятора Не факт. Вполне возможно, что рантайм-загрузку можно оптимизировать гораздо круче. Будет оптимизация на уровне дизайнера и гуи-либы. Цитата(S.A.P. @  10.3.2007,  09:52 ) В Qt в первом подходе это есть. Разница в том, что XML используется как промежуточный формат. Т.е. QtDesidner формирует XML, а uic компилирует его в C++ код. Возможность то есть, да она всегда есть. Даже скажем дизайнер VS для WinForms. Что ж пусть дизайнер рисует, как нарисует придём мы код писать. С uic имеем на самом деле тоже. Дизайнер решил немного изменить дизайн. Скажем вместо флажка поставить список да/нет (мож красивей смотрится). Отлично - переписыаем код. Если бы была привзяка данных к модели, было бы гораздо лучше. Цитата(S.A.P. @  10.3.2007,  09:52 ) с учётом вышесказанного это есть и в первом подходе. С учётом вышесказанного нету.    Цитата(mr.DUDA @  10.3.2007,  13:49 ) ельзя же дизайнить libglade и XAML одним универсальным средством рисования, раз оба отделяют код от дизайна Вообще говоря - плохо они отделяют. Привязка в обоих к коду жуткая. Хотелось бы реализацию (настоящую реализацию, а не мнимую) MVC на уровне ГУИ-фреймворков. Единственная попытка мне известная - у адобы. Они вообще похоже во всей ASL стремятся к красивому грамотному проектированию. Но либа ИМХО ужасная. Ничго серьёзного у меня с ней сотворить не получилось (я именно про гуй) :( mr.DUDA, иди я что-то туплю или что - не знаю, но про твою историю из будней дизайнеров не понял.    И ещё один минус первого варианта (чисто субъективный). Раз уж код генерится - хочется чтобы он был кодом, а не мусором (потому не люблю я скажем и YACC - спирит в 10 раз приятней). С хорошей либой (Qt, Swing) обычно руками немногим дольше получается написать - плюс приятно смотреть (для меня это важно - не пинать). С WinForms не пробовал, так как... не пробовал. Строго говоря, про свинг говорю, просто представляя сие. Нормально только с кутехой работал. Всмысле проекты серьёзные (боль-менее) были.

Автор: Sardar 11.3.2007, 00:42

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

Автор: Любитель 11.3.2007, 01:01

Цитата(Sardar @  11.3.2007,  00:42 ) "option-tooltip", "option-help" Енто, без сомнения, вообще пишет дизайнер (ну или кто-то ещё- не программер). Да и вообще я бы хотел, чтобы программер предоставлял список экшенов, которые меняют данные модели или иным образом общаются с гуем. Теперь дизайнер коннектит события к этим экшенам как хочет. А всякие банальные эфекты, тултипы и прочие тривиальные вещи вообще конектит в стиле многочисленных автоплей-креаторов или паувер-поинтов

Автор: S.A.P. 11.3.2007, 01:32

Любитель, не встречал подобные навороченные абстракции. ИМХО они только в воздухе летают как и многие другие идеальные вещи, а на деле все программируют как программируют. Цитата(Sardar @  11.3.2007,  00:42 ) "option-selected(selected-options)", "option-pointed(options)", "option-tooltip", "option-help"   всего не учёшь, надо от конкретного случая отталкиваться и если дизайнер решил заменить список на набор кнопок, то ничто его уже не спасёт   .

Автор: Любитель 11.3.2007, 01:44

Цитата(S.A.P. @  11.3.2007,  01:32 ) Любитель, не встречал подобные навороченные абстракции. ИМХО они только в воздухе летают как и многие другие идеальные вещи, а на деле все программируют как программируют. Однако MVC в гуи-либах развивается активно. Я верю - будет и такое. Поскореё бы... Добавлено @ 01:47  Очень хотелось бы услышать мнения Java-девелоперов.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)