Вот видишь, тебе лень читать, разбираться... Кусок кода что ты привел - это реализация custom-widget (то есть используется подход холста). Ты глянь лучше пример который создает окно с тремя кнопочками, списоком и чекбоксом. И то что Gtk-- сильно использует шаблоны не значит, что он STL-alike (просто так типы параметров сигналов легче заставлять соблюдать). И вообще, все диалоги делаются гуи-билдером, а не ручками, так что красота кода - не #1. А если тебе надо писать что-то типа текстового редактора или ГИС - то уж изволь все изучить. Короче, я хочу сказать, что gtk - на такой отстой как ты его расписываешь. И еще - gtk использует свою run-time type system с классами, свойствами, сигналами. Это облегчает интеграцию со скрпитовыми языками, прямую работу с gui-builders, а также widget-level customization ala Xdefaults. Система типов С++ не может дать всех этих возможностей, и поэтому в перечисленных аспектах QT (и другие C++-based библиотеки) посасывают.
Единственное достоинство Qt IMO - то что она, являясь коммерческим софтом, хорошо поддерживается, что без каких-либо нареканий работает под виндой. Но она не использует unix-way и не имеет академически-стройной архитектуры.
О lyx - они его щас делают widgetset-independant (с xforms, Qt, gnome интерфесами) - см. http://www.devel.lyx.org/guii.php3

2ivan4th:
> Только замечу, что изначальный создатель KDE,
> Matthias Ettrich, перешёл с XForms (LyX) на Qt
> и обратно не торопится
Для меня это имя -- синоним слова "ламер".
Если его интеллекта в свое время, по его собственному признанию,
не хватило на то, чтобы одолеть LaTeX, то что вообще можно ожидать
от его идей? LyX и KDE -- яркие тому примеры. Спасает его то,
что реализацией его идей сейчас занимаются другие лиди, которым
все равно, на чем деньги/авторитет зарабатывать.

2 last anonymous: тоесть утверждается, что C++ намного легче освоить, чем LaTeX? странное утверждение... 2 hvv: судя по коду для Gtk-- для 2D graphics надо на C писать. У Qt же есть весьма продвинутый 2D graphics engine (C++). Я не в полне понимаю, какая проблема с тем, чтобы что-то вроде Xdefaults зафигачить, если оно надо, под Qt. По-моему, проблем здесь нет, там меньше сотни строчек кода выйдет, чтобы читать из файла и устанавливать properties для любых виджетов. Не вижу, в чём трабл с GUI builders; напротив, Qt properties тут очень даже помогают. См. Qt Designer. Зато если я пишу на C под Gtk+ и все widgets у меня - GtkWidget *, то если я ошибусь и напишу GTK_BOX(x) где x - это не box, то получу непредсказуемый результат, и, возможно, геморрой до 5 утра. К утру, в конец переглючившись, человек лепит ещё десяток таких багов, и ещё 2 недели за ними гоняется ;) Далее, в качестве аргуметна gtk_signal_connect я передаю указатель на функцию (GTK_SIGNAL_FUNC(myfunc)). В Qt передаётся имя функции, const char * (e.g. dlg->connect(okButton, SIGNAL(clicked()), SLOT(accept())); ) (макросы SIGNAL и SLOT дают const char *). Казалось бы, указатель передать быстрее, зато если я напутал с аргументами, то опять же, моя программа легко уронит кору, причём, возможно, много позже. В случае Qt механизм signals/slots проверяет совпадение аргументов. Не знаю, может кому-то и нравится ночами гоняться за неуловимыми багами, но я предпочитаю их количество по возможности сократить.

> Я не в полне понимаю, какая проблема с тем,
> чтобы что-то вроде Xdefaults зафигачить, если оно надо, под Qt.
Чтобы каждому виджету можно было назначить свое оформление, размеры, параметры, акслераторы для него, и все это без участия программера (то есть чтобы либа все поддерживала)? 1К строк тут явно не хватит. А чтобы *во время* работы программы менять параметры виджета (без какой либо поддержки со стороны программы) мышкой (типа цвет, размеры) и вообще увидеть список его свойств и иметь возможность менять их ВО ВРЕМЯ РАБОТЫ софтины?
>Зато если я пишу на C под Gtk+ и все
>widgets у меня - GtkWidget *, то если я ошибусь и напишу GTK_BOX(x)
>где x - это не box, то получу непредсказуемый результат, и, возможно,
>геморрой до 5 утра. К утру, в конец переглючившись, человек лепит ещё
>десяток таких багов, и ещё 2 недели за ними гоняется ;) Далее, в
>качестве аргуметна gtk_signal_connect я передаю указатель на функцию
>(GTK_SIGNAL_FUNC(myfunc)). В Qt передаётся имя функции, const char *
>(e.g. dlg->connect(okButton, SIGNAL(clicked()), SLOT(accept())); )
>(макросы SIGNAL и SLOT дают const char *). Казалось бы, указатель
>передать быстрее, зато если я напутал с аргументами, то опять же, моя
>программа легко уронит кору, причём, возможно, много позже. В случае
>Qt механизм signals/slots проверяет совпадение аргументов.
Те проблемы, которые ты описал, справедливы при использовании родного интерфейса gtk+ (и кстати, ошибки в несоответствии типов будут отловлены в ран-тайм, не обязательно падением в кору - по любому gtk+ напишет что не может преобразовать тип GtkCList в GtkButton например). Если юзать gtk--, все это будет отловлено на этапе компиляции (вызовет ошибку компиляции из-за несовместимости типов). Так что сначала сам подумай, о чем ты говоришь.

2 hvv

Gtk-- я уже охарактеризовал. Работа с ним требует знания Gtk+, некоторые вещи, типа рисования, приходится делать с использованием C'шного gdk etc. По поводу customizing widgets без вмешательства в код программы - используя механизм properties в Qt, это легко уместить в заметно меньшее число строк, чем 1K. Через properties можно доступиться очень ко многому, хотя может и не столь многому, как в Xt (menu items, например - но для этого есть фишки вроде XML GUI в KDE). Текст на кнопочке задать, цвет, акселератор - не вопрос. Всё сводится к тому, чтобы написать коротенький парсер для строчек типа a.b*c:x и поставить обработчик childEvent у главного окошка, чтобы у вновь создаваемых виджетов значения проставлять. Изменение параметров во время работы - ну вот тут вычитал: http://www.motifzone.com/tmd/articles/Editres2/Editres2.html Other toolkits could perhaps also benefit from the editres protocol. It should be possible to write an event handler for the Qt library (used in the K desktop environment) or the TK widgets from the wish (Tcl/Tk or Perl/Tk). The editres2 program would not need to change. Event handler этот пишется аналогично тому, о чём шла речь выше. Помнится как-то была статья где-то какого-то защитника OSF/Motif, автор которой утверждал, что мол и Qt, и Gtk+ полный суксь потому что ничего подобного editres и X resources для них создать в принципе невозможно. В ответ, кажется, один из KDEшников написал editres для Qt или чего-то в этом духе ;) Искать только сейчас лениво.

Ну, по поводу сравнения GTK vs QT - это, конечно, вопрос сложный, но, по всей видимости, идеологически правильно :-) при программировании "в основном для X11" таки пользовать GTK (возможно, с обертками, в виде Gtk--, PyGTK, Perl/GTK). Причины, как мне представляется, довольно банальны: 1. GTK - это тулкит для X11/фрюникс, который умеет работать где-то еще (я видел виндовый порт, вроде, живое) QT - это тулкит для Windows, перенесенный в X. Какая разница? Разница прежде всего идеологическая. Посмотрите на GTK'шный fontsel виджет и его QT'шный аналог. Чувствуете разницу? Где вы можете доступиться до всех известных X'е свойств фонта (и, для программеров, быстренько создать fontset с заданными свойствами)? Правильно, в GTK. Посмотрите на то, как сделана локализация в QT и GTK. Я по необходимости влазил в QT'шный сорец, касающийся поддержки ru_* (кажется, это была Qt-2.0.x - QT-2.1.x, но точно вторая). От некоторых мест с автоугадавом у меня волосы дыбом становились, ей-богу. И таких претензий много. 2. Я хочу поддержку X Resources. Сейчас ее нет ни там, ни там, но в GTK, с их явно вынесенными .gtkrc, иерархическими "widget" и "class" и gtk_style, по крайней мере, просматриваются простые пути их, XRes, использования. 3. За libglade и близкий к нормальному pack-manager GTK'шным писателям можно многое простить :-)

Опять же повторяюсь, странные вы какие-то:

1) KDE/Qt коммерциализованные поуши. Коммерческий софт под них писать можно только заплатив за лицензию на Qt, LGPL у KDE-библиотек позволяет лишь делать коммерческий софт под KDE заплатив за Qt. И чтобы привлеч пользователей к "халявному поуши" KDE.

2) "Налоговой" можно показывать красивые бумажки из коробки с RedHat, это их должно удовлетворить.

3) Опять же контекстно-ориентированная реклама это совершенно нормально и правильно для Internet. Google надо сказать отдельное спасибо что эта реклама идет как 'Sponsored links', а не в перемешку со ссылками как у некоторых других.

ну значит, нет компаний типа theKompany, специализирующихся на GNOME?
ну все равно коммерческий софт лучше под Гном писать... =)