Qt 4.2 Release!

Спасибо за жизненный пример динамического интерфейса%)

Соббсно, интерфейс ужаснейшей закладки "Layout Options" в гноме - тоже динамический. Но к .glade это отношения не имеет...

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

Да они не то чтобы какие-то особенные "промежуточные". Обчный код, который вполне можно набить и руками, кто-то именно так и предпочитает:

void setupUi(QMainWindow *dlg_exampleClass)
{
dlg_exampleClass->setObjectName(QString::fromUtf8("dlg_exampleClass" ;));
dlg_exampleClass->resize(QSize(600, 400).expandedTo(dlg_exampleClass->minimumSizeHint()));
centralWidget = new QWidget(dlg_exampleClass);
centralWidget->setObjectName(QString::fromUtf8("centralWidget"));
gridLayout = new QGridLayout(centralWidget);
gridLayout->setSpacing(6);
gridLayout->setMargin(9);
gridLayout->setObjectName(QString::fromUtf8("gridLayout"));
splitter = new QSplitter(centralWidget);
splitter->setObjectName(QString::fromUtf8("splitter"));
splitter->setOrientation(Qt::Horizontal);
widget = new QWidget(splitter);
widget->setObjectName(QString::fromUtf8("widget"));
vboxLayout = new QVBoxLayout(widget);
vboxLayout->setSpacing(6);
vboxLayout->setMargin(0);
vboxLayout->setObjectName(QString::fromUtf8("vboxLayout"));
hboxLayout = new QHBoxLayout();
hboxLayout->setSpacing(6);
hboxLayout->setMargin(0);
hboxLayout->setObjectName(QString::fromUtf8("hboxLayout"));
label = new QLabel(widget);
label->setObjectName(QString::fromUtf8("label"));
....
}

> у меня в сущьности аналогичный вопрос. для MSVC .Net 2003 в варианте release это будет выглядить как:
> -rwx------+ 1 foo foo 1490944 Oct 5 17:26 QtCore4.dll
> -rwx------+ 1 foo foo 3227648 Oct 5 17:51 QtGui4.dll
> -rwx------+ 1 foo foo 45056 Oct 5 17:52 findfiles.exe

у меня сейчас нет под рукой mingw, но тот-же qt собранный на bsd с использованием g++ 4.1.2 после стрипа выглядит примерно так:

-rwxr-xr-x 1 foo foo 1613756 Oct 5 20:27 libQtCore.so.4.1.4
-rwxr-xr-x 1 foo foo 4512140 Oct 5 20:27 libQtGui.so.4.1.4

это конечно же не в два раза больше, но все-таки немного больше. впрочем, это не суть важно. а вот mingw 3.x [или 4.x? уже не помню] выдавал мне действительно удвоенный размер по сравнению с MSVC.

// wbr

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

> Да видел я этот код, его и glade умеет.

умел. в 3-м glade эта бесполезная функциональность была выкинута на помойку истории

Да, точно. Я даже внимания не обратил. Впрочем, я думаю, не один я. В гноме уже так давно никто этой ерундой не занимается...

> Да, точно. Я даже внимания не обратил. Впрочем, я думаю, не один я. В гноме уже так давно никто этой ерундой не занимается...

Правильно, в основу Gnome положен железный принцип - есть единственно правильный путь решения задачи, и мы им пойдем. Это Qtшники/KDEшники разбалованы выбором: понадобится - код сгенерируют, понадобится - XML подгрузят.

С другой стороны, я авторов glade понимаю. С учетом объектной модели Glib (точнее, ее реализации), да и стараниями Gtk, код мало-мальски сложного диалога разрастается до таких размеров, что не на всякий винт влезет ;-)

> Гхм. Мне казалось, в kde есть аналог libglade?

http://doc.trolltech.com/3.3/qwidgetfactory.html :)

Это была попытка доказать, что надо было сохранить никем не используемый код - или просто продолжение флейма ради флейма?;)

Претензии к объектной модели gtk мы начнем принимать в тот день, когда появится стандарт на кросс-языковый ОО ABI под унихом. А до тех пор - в приемную М.И.Калинина.

> или просто продолжение флейма ради флейма?;)

Это не флейм - это шутки. Видите смайлик? :)

> Это не флейм - это шутки. Видите смайлик? :)

В каждой шутке есть доля флейма! Видите url www.linux.org.ru? ;)

>Да видел я этот код, его и glade умеет. Просто когда человек видит этот код, у него может возникнуть непроизвольное желание его "улучшить". А вот за это надо сразу делать "секир-башка".

Сказать честно? Я этот код видел всего 2 раза: первый раз когда задался вопросом "а что это за файлы появляются?", второй раз --- сегодня =)

И у меня как-то не возникало желания "улучшить". Просто потому что тогда возникает вопрос: а нафига вообще пользоваться дизайнером, если потом все равно правишь вручную? =)

> Ну что за агрессивное стремление доказать: что A - есть хорошо, а B - есть плохо и должно умереть. Каждому инстурменту найдется свое применение.

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

Какое-то ограниченное применение данная идея найти может, но - не более того.

XML хорош для стандартных виджетов, а если на форме главного окна у меня 2 десятка самописных виджетов - то тут без генерации промежуточного C++ кода никак не обойтись, благо С++ позволяет субклассинг, а QtDesigner позволяет очень просто интегрировать в себя самописные виджеты.

В древние времена моей молодости билдеры интерфейсов в жабке были убогими. Так что иногда мне приходилось развлекаться тем, что я брал сгенеренный код (о-оо, что это был за код!) и воспринимал его как ... "нулевую итерацию". Затем причесывал до вменяемого состояния. С тех пор у меня на этом месте легкая паранойя: если есть возможность добраться до кода, найдется идиот, который это сделает;)

В таком случае если у юзера есть возможность поправить XML и тем самым испортить его, то он это обязательно сделает :D

Фигня вопрос! Зазипуем! security through obscurity uber allez!

Наконец-то теперь значит и PSI скоро обновят

>Я для заказчика пишу всё на Qt. Поэтому я просто скопировал ему в c:\Qt\4.1.4 (ну, и настроил переменные среды) ВСЕ файлы qt, которые могут понадобиться в runtime. Это заняло ровно 9.765.059 байт. ВСЁ.

А зачем это, эти несколько dll нужно было в windows/system32 скопировать, а переменные среды, (всякие там QTDIR,) вообще не нужно настраивать, если не ведется разработка на этом компе

>> Гхм. Мне казалось, в kde есть аналог libglade? Я ошибался? Можно использовать файлы .ui динамически, прямо из программы - или обязательно из них генерить плюсовый код?

>imho - из них обязательно генерить плюсовый код.

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

Для справки:

[cas@merlin-cas kdebase-3.5.4]$ find . -name \*.ui | wc -l
115

> СТО кнопок???? Господи, как же я не завидую тем, кто будет пользовать Ваши "продукты"...

Это просто пример. Нужен реальный? Есть система, система старая, обмен данными организован с помощью упакованных сишных структур. Задача организовать просмотр значений этих структур через графический интерфейс. Насколько я понял, ты предпочтешь решение, на каждый тип структуры создавать в дизайнере ui файл? Или я неправильно понял?

> В подавляющем большинстве случаев реальные формы содержать РАЗНЫЕ компоненты. И дизайнить их однозначно удобнее визуальными средствами - сразу видно, что получается.

Про удобство в данном случае не спорю, но не надо это называть автоматизацией.

> А это, видимо, мне адресовалось. Моё понятие об автоматизации таково: Процесс освобождения человека от рутинного труда (здесь - тупое написание кода без творческой составляющей) путём передачи этой функции машинам.

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

> А Ваше?

По определению совпадает с твоим, только видение проблем другое.

> Правильно, в основу Gnome положен железный принцип - есть единственно правильный путь решения задачи, и мы им пойдем. Это Qtшники/KDEшники разбалованы выбором: понадобится - код сгенерируют, понадобится - XML подгрузят.

Для glade тоже никто не запрещает код генерировать.

> Задача организовать просмотр значений этих структур через графический интерфейс. Насколько я понял, ты предпочтешь решение, на каждый тип структуры создавать в дизайнере ui файл? Или я неправильно понял?

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

> Про удобство в данном случае не спорю, но не надо это называть автоматизацией.

Как раз можно и нужно. Это придаёт дополнительную гибкость, так как можно разделить бэкенд и фронтэнд.

> О, да. Таскание виджетов на форму самая творческая для программиста работа.

Скажем так, самая ненапряжная.

> Чем в нашем случае работа мышью сильно отличается от работы клавиатурой?

Экономится куча времени и обеспечивается куда как бОльшая гибкость. :)

> Фалы ui в этом случае генеряться, а дальше красиво упаковываются,

Кем? Кутешным дизайнером? Как пункт в меню называется? Хочу попробовать.

> Это более гибкое решение, чем жёско кодить интерфейс вручную.

Я и не предлагал кодировать интерфейс вручную.

>> Про удобство в данном случае не спорю, но не надо это называть автоматизацией.

> Как раз можно и нужно. Это придаёт дополнительную гибкость, так как можно разделить бэкенд и фронтэнд.

А если мы пишем ui файл руками, то это тоже автоматическое создание интерфейса? Фаза кодогенерации никуда же не пропадает.

Попались, да? :)

>> О, да. Таскание виджетов на форму самая творческая для программиста работа.

> Скажем так, самая ненапряжная.

Но монотонная и малоинтересная (как и ручное кодирование интерфейса).

> Кем? Кутешным дизайнером? Как пункт в меню называется? Хочу попробовать.

Нет, любым скриптовым языком :)

> Я и не предлагал кодировать интерфейс вручную.

А чего тогда на дизайнер взъелись?

> А если мы пишем ui файл руками, то это тоже автоматическое создание интерфейса? Фаза кодогенерации никуда же не пропадает. Попались, да? :)

Нет, не попался! Если в формате UI, то можно поправить, а потом подключить динамически. Кто там говорил про "кодогенерацию"? :)

> Но монотонная и малоинтересная (как и ручное кодирование интерфейса).

Это он недостатка вкуса. :)

>>эта бесполезная функциональность была выкинута на помойку истории

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

>>Для glade тоже никто не запрещает код генерировать.
Какой смысл? Ну, для С/С++ какой-то плюс есть засчёт скорости, но для интерпретаторов парсинг XML с помощью библиотек всяко быстрее получается, чем интерпретация собственно кода.

>>>XML хорош для стандартных виджетов, а если на форме главного окна у меня 2 десятка самописных виджетов
Кстати да, интересно было бы посмотреть на документацию, как встроить в GUI-designer (например, glade) свой собственный widget.

> Нет, любым скриптовым языком :)

Не подскажешь, какой лучше всего подходит. :)

> А чего тогда на дизайнер взъелись?

Я про дизайнеры интерфейсов слова плохого не сказал, только хорошее.

> Нет, не попался! Если в формате UI, то можно поправить, а потом подключить динамически. Кто там говорил про "кодогенерацию"? :)

Ты и еще пара товарищей -- дизайнеров-автоматчиков.

> Это он недостатка вкуса. :)

И еще от лени. :)

Говорили про возможность такого подхода для glade. А есть смысл или нет, каждый решает сам.

> Не подскажешь, какой лучше всего подходит. :)

Смотря с чем лучше знаком и на чём делается прототипирование. Perl (если знаешь) или Python.

> Фигня вопрос! Зазипуем! security through obscurity uber allez!

Ну зачем же так блистать своим невежеством? "uber allez" пишется как "ueber alles".

Во-вторых. И эти люди ещё удивляются, когда пользователи рассказывают им про тормоза их гномов и гытыкы.

> А зачем это, эти несколько dll нужно было в windows/system32 скопировать, а переменные среды, (всякие там QTDIR,) вообще не нужно настраивать, если не ведется разработка на этом компе

Для простоты обновления Qt при случае. Я сразу вижу, какой оно версии и какие файлы нужны. Выковыривать их из срача по имени "windows\system32" - задача не особо приятная.

> Про удобство в данном случае не спорю, но не надо это называть автоматизацией.

Есть такие интересные люди, для которых стереотипы превыше логики. amm - один из них. Логика подсказывает: "код генерится автоматически, юзер его не пишет - значит, автоматизация". Стереотип подсказывает: "наши деды и прадеды не называли мышевозные средства создания GUI автоматизацией - и мы не будем". Стереотип ему милее...

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

Конечно. Творческая работа по размещению кнопок на форме там, где это будет лучше всего. Быстро и эффективно. Вместо тупого и долгого написания одного и того же кода. Поместить кнопку на форму - ОДНО движение мыши и нажатие её кнопки. А с написанием кода - множество нажатий клавиш.

> Есть такие интересные люди, для которых стереотипы превыше логики. amm - один из них.

А есть люди, которые врут (сознательно или несознательно, не знаю), anonymous (*) (07.10.2006 12:07:30) один из них.

> Логика подсказывает: "код генерится автоматически, юзер его не пишет - значит, автоматизация".

А если ui файл пишется руками? А если генерация заменяется динамической загрузкой? Тогда твоя "стройная" логика ломается?

И куда начало цепочки делось? Про автоматизацию мы говорили в контексте создания интерфейса, а не генерации кода. Если говорить про первое, то дизайнеры интерфейсов звено вообще лишнее, если про второе то только опциональное.

> Стереотип подсказывает: "наши деды и прадеды не называли мышевозные средства создания GUI автоматизацией - и мы не будем". Стереотип ему милее...

Я такого не говорил. Да и деды у меня по своей работе были далеки от ИТ.

> Смотря с чем лучше знаком и на чём делается прототипирование. Perl (если знаешь) или Python.

В эти языки встроен сишный парсер?

> В эти языки встроен сишный парсер?

А причём тут сишный парсер, друк?

> Конечно. Творческая работа по размещению кнопок на форме там, где это будет лучше всего. Быстро и эффективно. Вместо тупого и долгого написания одного и того же кода.

Код один и тот же, а кнопки разные. Хорошо, запомню. :)

Смотри задачу: если обмен идет сишными структурами, то наверно, они описаны в заголовочниках.

Не знаю, как там в перле, а в питоне делаешь import ctypes и обмениваешься какими хочешь структурами, а сишный парсер у нормального программиста встроен прямо в моск, и вообще он не обломается написать конвертилку из .h в .py. :D

>VisualStudio - кривая поделка. Кстати, сколько ты отслюнявил за >коммерческую версию Qt? Думаю, у тебя есть все основания воспользоваться >их support'ом.

>anonymous (*) (04.10.2006 21:24:44)

5 баллов :-))
Понаставят крякнутого софта , потом жалуются мля...

>> Логика подсказывает: "код генерится автоматически, юзер его не пишет - значит, автоматизация".

> А если ui файл пишется руками? А если генерация заменяется динамической загрузкой? Тогда твоя "стройная" логика ломается?

А если у бабушки есть яйца, то это уже дедушка. Любое средство автоматизации можно использовать для другой цели. Например, забивать им гвозди. Оно перестаёт от этого быть средством автоматизации?

> Если говорить про первое, то дизайнеры интерфейсов звено вообще лишнее, если про второе то только опциональное.

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

> Не знаю, как там в перле, а в питоне делаешь import ctypes и обмениваешься какими хочешь структурами, а сишный парсер у нормального программиста встроен прямо в моск, и вообще он не обломается написать конвертилку из .h в .py. :D

Про то и разговор.

Как говорится, слив засчитан.

>Претензии к объектной модели gtk мы начнем принимать в тот день, когда появится стандарт на кросс-языковый ОО ABI под унихом. А до тех пор - в приемную М.И.Калинина.

http://en.wikipedia.org/wiki/Objective_C