KDE ждёт быстрая смерть?

> чегото похоже" - это суксь

Ну ты покажи это самое, сделанное на C. Пример на питоне не катит хотя бы потому, что gtk -- не питоновый.

> В qt получается, что передать можно только sender, а если сигнал получает не только один этот объект?

Про this ты тоже забыл?

> ЕМНИП, на сигнал в Qt вешается только функция. Не объект.

Ну так сигнал-маппером можно передать в функцию любой объект и с ним работать.

>> 4.2 + 4.2 == 8.4 :)

> ну добавь. А я посмотрю.

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

>Отлично! Только вот это окошко должно быть общим для всех программ на десктопе. А это не используется в широкораспространённых DE :(

это в каких? В гноме - используется.

>Да. Но это должны быть не только модули gtk.

не только - смотри третий вариант. Кажется, это то, что ты искал.

=)

>Простейшие виджеты и частоиспользуемые диалоги, будь то отображалка картинки, файловый диалог или toolbar, должны быть общими и легкоподменяемыми.

как ты себе это представляешь? Архитектурку набросай. Я пока знаю, как обеспечить поддержку этих абстрактных "стандартных виджетов" в гтк-приложениях :)

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

зачем? почему не в виде плагина? Ах да, я забыл, что говнотулкиты не умеют плагины

=)

>> Архитектурно правильное решение -- не использовать программы не написанные на gtk? Вещь в себе.

> gtk? нет.

Да. Программы на gtk списываются только в gtk-шный DE, а не в любую другую среду. Следовательно, вещь в себе.

И даже qt-engines-gtk отсутствует, в отличие от обратного :)

> Ибо и вне DE неплохо живут. и в DE интегрируются.

В kde не интегрируются, в explorer.exe не интегрируются. В CDE тоже не интегрируются. Ну и, где интеграфия?

>> Тут просто не надо использовать компилируемые языки.

> напиши на tcl/tk blender и inkscape

Начался фигурный квотинг. Куда ты дел слова "маршалер", "dbus" и "замыкание"?

>> Dbus -- начнём с того, что он нарушает правило "универсальный формат данных -- текстовый поток".

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

man unix_way. Как раз оттуда взято :)

>> Они никоим образом к glib не привязаны(слава Патрику :)).

> GObject - это Qt и всё внутрь себя не тащит

Зато заставляет таскать за собой glib.

>> А то, что они не использованы ни в kio, ни в gnomevfs/gio -- это действительно проблема обоих велосипедов.

> почему же, в gio используется. Как сервис-редиректор. =)

ТО есть не по-назначению.

>> Там можно задать дефолтный каталог? Список расширений?

> в gtkdialog можно. Для ещё более навороченного можно юзать gtkserver - и писать gtk-приложения на баше

А gtkserver не нужен. Нужно просто легко сочетать виджеты и стандартные диалоги так же, как чосетаются sed|grep|awk и прочие базовые утилиты unix-системы.

> kdialog ... прибит гвоздями к KDE.

Вот. Более того, наверняка и параметры запуска у gtkdialog, kdialog и zenity различны. Что плохо, ибо нельзя их прозрачно подменять.

>Ну ты покажи это самое, сделанное на C. Пример на питоне не катит хотя бы потому, что gtk -- не питоновый.

ты видимо ниасилил мысль. Повторюсь - замыкания используются биндингами. в с это называется g_signal_connect_closure()

>Про this ты тоже забыл?

this - тоже не контекст,ага

>Ну так сигнал-маппером можно передать в функцию любой объект и с ним работать.

и опять-таки не замыкания, а костыль, чтобы не писать по обработчику на сигнал для уже известного контекста. Насколько я понял, SignalMapper подменяет sender и всё

>> Ну ты покажи это самое, сделанное на C. Пример на питоне не катит хотя бы потому, что gtk -- не питоновый.

> ты видимо ниасилил мысль. Повторюсь - замыкания используются биндингами. в с это называется g_signal_connect_closure()

Показывай пример. Или чтобы использовать замыкания, обязательно писать на пистоне?

>> Про this ты тоже забыл?

> this - тоже не контекст,ага

Для определения отсылателя и получателя и доступа к их свойствам достаточно sender() и this соответственно.

>> Ну так сигнал-маппером можно передать в функцию любой объект и с ним работать.

> и опять-таки не замыкания, а костыль, чтобы не писать по обработчику на сигнал для уже известного контекста.

Недостаток языка.

> Насколько я понял, SignalMapper подменяет sender и всё

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

>Начался фигурный квотинг. Куда ты дел слова "маршалер", "dbus" и "замыкание"?

ну так они скриптуются. inkscape в частности - питоном :) блендер не на гтк, но тоже скриптуется питоном и использует замыкания с маршалерами

>man unix_way. Как раз оттуда взято :)

чушь собачья. Нету в юнихвей требования о тексте в IPC. Хотя ты всегда можешь себе такое правило придумать и выкинуть иксы нахрен =)

>> Начался фигурный квотинг. Куда ты дел слова "маршалер", "dbus" и "замыкание"?

> ну так они скриптуются. inkscape в частности - питоном :) блендер не на гтк, но тоже скриптуется питоном и использует замыкания с маршалерами

И где тут используются преимущества gtk/glib? Не вижу.

> напиши на tcl/tk blender и inkscape

Ну так кто мешяет делать скрипты на tcl, гуй на tk, а критичные по скорости куски на C/C++/чём угодно?

В tcl встраивание кусков на C предусмотрено и отлично работает. Вон в соседнем отделе гнусная проприетарщина написана на c++/tk и всё шустро работает и быстро разрабатывается.

>Показывай пример. Или чтобы использовать замыкания, обязательно писать на пистоне?

любой биндинг требует замыканий. По идее

>Для определения отсылателя и получателя и доступа к их свойствам достаточно sender() и this соответственно.

кто тебе сказал, что контекст - это отправлятель и посылатель? В контексте в общем могут быть любые данные. Например, туда можно засунуть ссылку на список объектов. И обработчик сигнала будет работать по этому списку

>Недостаток языка.

как раз на c++ замыкания реализовать можно. Таким же способом, как это сделанов glib/gobject. Так что это не недостаток языка, а недостаток конкретно Qt

>Неправильно понял. SignalMapper передаёт дополнительный параметр в обаботчик сигнала.

значит this подменяет. Это не дополнительный параметр, а стандартный =)

см. http://qt.osdn.org.ua/signalmapper.html

короче, не замыкание :) Костыль, позволяющий обойти ограничение слотов и сигналов Qt

>И где тут используются преимущества gtk/glib? Не вижу.

в биндингах =)

>Ну так кто мешяет делать скрипты на tcl, гуй на tk, а критичные по скорости куски на C/C++/чём угодно?

в векторных редакторах гуй - критичный по скорости кусок =)

>Вон в соседнем отделе гнусная проприетарщина написана на c++/tk и всё шустро работает и быстро разрабатывается.

охотно верю. Морды к бд можно и на tk писать, хотя лучше на питоне, ибо tk - СТРАШНЫЙ ШОПЕСТЕЦ

=)

> Нету в юнихвей требования о тексте в IPC.

"Пишите программы, которые бы поддерживали текстовые потоки, поскольку это универсальный интерфейс."

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

Мне, кстати, более нравится dcop из за его текст-ориентированности.

> Хотя ты всегда можешь себе такое правило придумать и выкинуть иксы нахрен =)

Иксы не надо, а вот DE в текущем их состоянии -- надо выбросить, да подальше. Я ведь кедами пользуюсь только потому, что труЪ-де в моём понимании нет.

>> Показывай пример. Или чтобы использовать замыкания, обязательно писать на пистоне?

> любой биндинг требует замыканий. По идее

Ну так пример будет или как?

>> Для определения отсылателя и получателя и доступа к их свойствам достаточно sender() и this соответственно.

> кто тебе сказал, что контекст - это отправлятель и посылатель? В контексте в общем могут быть любые данные. Например, туда можно засунуть ссылку на список объектов. И обработчик сигнала будет работать по этому списку

В кутях можно передать любой объект. И всё это без подмены sender и this. А в статье по ссылке написана какая-то ху-ня, так что нечего на неё ссылаться.

>> Недостаток языка.

> как раз на c++ замыкания реализовать можно. Таким же способом, как это сделанов glib/gobject.

Ты мне код покажи, а не говори "таким же способом".

>"Пишите программы, которые бы поддерживали текстовые потоки, поскольку это универсальный интерфейс."

это цитата тех времен, когда все программы работали исключительно с текстом. Ты сам-то понимаешь, что в случае X11 например это _невыполнимо_? Если передается не текст - нахера текстовый поток?

зы: контекст высказывания глянь еще. Там говорится про пайпы stdin/stdout =)

>Мне, кстати, более нравится dcop из за его текст-ориентированности.

RIP

>Иксы не надо

а почему? ведь текстовый поток - труъ. Ещё и IPC в ядре надо текстовыми сообщениями делать. Это тоже будет ТРУЪ

>Я ведь кедами пользуюсь только потому, что труЪ-де в моём понимании нет.

гениальная фраза. Пожалуй, запишу

а где про труъ-DE почитать можно? А то вот отдна есть - виндовс - там все стандартизированно и однообразно покрашено песком (ц) Может тебе туда? =)

>> И где тут используются преимущества gtk/glib? Не вижу.

> в биндингах =)

ТО есть нигде.

>> Ну так кто мешяет делать скрипты на tcl, гуй на tk, а критичные по скорости куски на C/C++/чём угодно?

> в векторных редакторах гуй - критичный по скорости кусок =)

Не весь гуй, а только canvas, на котором рисуется то, что редактируешь. А _весь_ этот canvas можно рисовать из сишной/сиплюсплюсной процедуры.

>> Вон в соседнем отделе гнусная проприетарщина написана на c++/tk и всё шустро работает и быстро разрабатывается.

> охотно верю. Морды к бд можно и на tk писать, хотя лучше на питоне,

В том-то и дело, что это не морда к бд, а программа управления и анализа работы gsm-сети.

> ибо tk - СТРАШНЫЙ ШОПЕСТЕЦ

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

>Ну так пример будет или как?

dbus-glib, смотреть экспорт объектов на шину, можно грепать по g_signal_connect_closure

или опять не нравится? :)

>В кутях можно передать любой объект. И всё это без подмены sender и this.

примерчик покажешь? :)

>Ты мне код покажи, а не говори "таким же способом".

эм. сам можешь глянуть. код glib никто не закрывал =) Или ты хочешь, чтобы я копипастом занимался? =)

>ТО есть нигде.

странный ты. $apt-cache search gtk bindings

и апстену :)

>Не весь гуй, а только canvas, на котором рисуется то, что редактируешь. А _весь_ этот canvas можно рисовать из сишной/сиплюсплюсной процедуры.

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

>В том-то и дело, что это не морда к бд, а программа управления и анализа работы gsm-сети.

однохерственно. интерактивность там аналогичная =)

>да и не было 15 лет назад красивых гуёв

это, очнись, чувак! 15 лет прошло =)

>>> ну так они скриптуются. inkscape в частности - питоном :) блендер не на гтк, но тоже скриптуется питоном и использует замыкания с маршалерами

>> ну и где тут сила gtk?

> в биндингах

Ну и? Чем в описанных задачах помогли биндинги к графическому тулкиту? (спеециально тред восстановил)

> на передачу упровляющих событий и нотификаций из канваса в гуй очень большой оверхед будет.

Откуда он возьмётся в сравнении с имеющимися решениями? Сообщения и так передаются, а рисование и так ведётся на канвасе.

Кстати, я вспомнил векторный редактор на tcl/tk. sK1 называется, и авторы его бродя где-то на ЛОРе :)

>> В том-то и дело, что это не морда к бд, а программа управления и анализа работы gsm-сети.

> однохерственно. интерактивность там аналогичная =)

Ну ты её, допустим, не видел. Интерактивность там на уровне игры Zuma, т.е. много чего мигает моргает, только успевай мышой тыкать :)

>> да и не было 15 лет назад красивых гуёв

> это, очнись, чувак! 15 лет прошло =)

Зачем переделывать то, что не сломалось?

>Ну и? Чем в описанных задачах помогли биндинги к графическому тулкиту? (спеециально тред восстановил)

гм, по-твоему, сами биндинги - не задача?

>Откуда он возьмётся в сравнении с имеющимися решениями? Сообщения и так передаются, а рисование и так ведётся на канвасе.

диалоги эффектов с превью, да мало ли что. Впрочем, ты волен писать как тебе угодно. =)

>Кстати, я вспомнил векторный редактор на tcl/tk. sK1 называется, и авторы его бродя где-то на ЛОРе :)

видел. Он тоже СТРАШНЫЙ

:)

>Ну ты её, допустим, не видел. Интерактивность там на уровне игры Zuma, т.е. много чего мигает моргает, только успевай мышой тыкать :)

у меня некоторые морды к некоторым бд мигают и моргают =)

>Зачем переделывать то, что не сломалось?

логично. Надо переделывать то, что не работает - в частности - Qt и KDE

=)

>> В кутях можно передать любой объект. И всё это без подмены sender и this.

> примерчик покажешь? :)

вечером будет.

>> Ты мне код покажи, а не говори "таким же способом".

> эм. сам можешь глянуть. код glib никто не закрывал =) Или ты хочешь, чтобы я копипастом занимался? =)

Осмысленный копипаст тоже хорош.

> можно грепать по g_signal_connect_closure

Посмотрел, что это такое... Мда, кутешникам до такого изврата додуматься не удалось, у них сигналы и обработчики хотя бы выглядят просто. И без маршаллеров!

>Посмотрел, что это такое... Мда, кутешникам до такого изврата додуматься не удалось, у них сигналы и обработчики хотя бы выглядят просто. И без маршаллеров!

кроме замыканий на сигнал можно повесить и обычную функцию. Сюрприз? :)

>> Зачем переделывать то, что не сломалось?

> логично. Надо переделывать то, что не работает - в частности - Qt и KDE

Оно работает. Только обладает тем же интегрированным синдромом, что и гном с гтк :)

>> Ну и? Чем в описанных задачах помогли биндинги к графическому тулкиту? (спеециально тред восстановил)

> гм, по-твоему, сами биндинги - не задача?

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

>> Откуда он возьмётся в сравнении с имеющимися решениями? Сообщения и так передаются, а рисование и так ведётся на канвасе.

> диалоги эффектов с превью, да мало ли что. Впрочем, ты волен писать как тебе угодно. =)

Высасываешь из пальца. (боюсь предположить, из какого :) )

>> Кстати, я вспомнил векторный редактор на tcl/tk. sK1 называется, и авторы его бродя где-то на ЛОРе :)

> видел. Он тоже СТРАШНЫЙ

А это не важно. Важно только то, что гуй написан на tk и ничего не тормозит.

>> Посмотрел, что это такое... Мда, кутешникам до такого изврата додуматься не удалось, у них сигналы и обработчики хотя бы выглядят просто. И без маршаллеров!

> кроме замыканий на сигнал можно повесить и обычную функцию. Сюрприз? :)

Это хорошо. А то бы вообще никто не осилил :)

>да ну? Заменен? звездишь.

Ну хоть чуть-чуть думай, блин, ну хоть чуть-чуть.... %\

>в qt3

Там и не было.

>в kde4

Ничего сказать не могу, ибо не видел.

>в qt4

Это какой-то неправильный qt4.. :) Начнём с начала: ты открываешь диалог выбора файла qt4, фокус находится на поле ввода, нажимаешь "/", появляется менюшка со списком каталогов и файлов в корне. Так?

>да нихрена. Оставшиеся продолжают работать, и их всегда можно перекинуть на другой фронт работ =)

Прям как в анекдоте: Идёт мужик, смотрит --- 2 мужика работает. Один ямы копает, другой их закапывает. Он спрашивает: "А чего у вас один ямы копает, а второй закапывает?" "А я не второй, я третий. Второй обычно саженцы в ямы суёт, но он сегодня на работу не вышел".

Так и у тебя: сломалась молотилка --- да пофиг, всё равно будем косить, а потом сразу веять %)

"Другого фронта работ" в программе нет.

>> В кутях можно передать любой объект. И всё это без подмены sender и this.

> примерчик покажешь? :)

Вот примерчик. QSignalMapper действительно изменяет значение, которое будет возвращено по вызову sender(), но путём подстановки в качестве параметра структуры, в которую поле нужного сендера вносится на этапе маппинга, это решается.

class GovnoClass {
private:
QString m_s;
public:
GovnoClass(const QString &str):m_s(str) {};

void run(void *_sender, void *_this) {
QMessageBox::information(NULL,"test geek",QString("%1\nsender: %2\nthis: %3").arg(m_s).arg(int(_sender)).arg(int(_this)));
}
};

class geek: public QWidget, private Ui::Form {
Q_OBJECT
public:
geek(QWidget* parent = 0, Qt::WFlags fl = 0 );
~geek();
private:
QSignalMapper *signalMapper;
GovnoClass *g;
private slots:
void megaSlot(QObject *obj);
void clickSlot();
};

-------------

geek::geek(QWidget* parent, Qt::WFlags fl): QWidget( parent, fl ), Ui::Form() {
setupUi(this);
g=new GovnoClass("jopa");
signalMapper=new QSignalMapper(this);
connect(pushButton,SIGNAL(clicked()),signalMapper,SLOT(map()));
connect(pushButton,SIGNAL(clicked()),this,SLOT(clickSlot()));
connect(signalMapper,SIGNAL(mapped(QObject*)),this,SLOT(megaSlot(QObject *)));
signalMapper->setMapping(pushButton,(QObject*)g);
}

geek::~geek() {
delete g;
delete signalMapper;
}

void geek::megaSlot(QObject * obj) {
((GovnoClass*)obj)->run(sender(),this);
}

void geek::clickSlot() {
QMessageBox::information(NULL,"test geek",QString("sender: %2\nthis: %3").arg(int(sender())).arg(int(this)));
}

на ЛОР как на работу

пока я твой код разгребать буду - посмотри, о чем я говорю.


-- cut --

static GObject* (*old_gtk_file_chooser_dialog_constructor)(GType type, guint n_construct_properties, GObjectConstructParam *construct_params) = NULL;


GObject* new_gtk_file_chooser_dialog_constructor (GType type, guint n_construct_properties, GObjectConstructParam *construct_params)
{
printf("MyGtkFileChooserDialog\n");
return old_gtk_file_chooser_dialog_constructor(type,n_construct_properties,construct_p arams);
}


G_MODULE_EXPORT void
gtk_module_init (gint * argc, gchar *** argv)
{
GtkWidget *fc;
GObjectClass *klass;
fc = gtk_file_chooser_dialog_new("hooked",
NULL,
GTK_FILE_CHOOSER_ACTION_OPEN,
GTK_STOCK_CANCEL,
GTK_RESPONSE_CANCEL,
GTK_STOCK_OPEN,
GTK_RESPONSE_ACCEPT,
NULL);
klass = G_OBJECT_GET_CLASS(fc);
old_gtk_file_chooser_dialog_constructor = klass->constructor;
klass->constructor = new_gtk_file_chooser_dialog_constructor;

}

-- cut --

gcc gtkmodule.c -o libfilechooser.so -I/usr/include/gtk-2.0 -I/usr/lib/glib-2.0/include/ -I/usr/lib/gtk-2.0/include/ -I/usr/include/atk-1.0/ -shared -lglib-2.0 -lgobject-2.0

кладем бинарник в /usr/lib/gtk-2.0/modules и пускаем в терминале:

GTK_MODULES="filechooser" какое-нибудь гтк-приложение

NB: в примере дергается оригинальный конструктор, для замены
достаточно заимплементить свой диалог, реализующий интерфейс GtkFileChooserIface.

>Ну хоть чуть-чуть думай, блин, ну хоть чуть-чуть.... %\

что тут думать? В трёх Qt-based аппликухах разные диалоги. Видно невооруженным глазом =)

>Начнём с начала: ты открываешь диалог выбора файла qt4, фокус находится на поле ввода, нажимаешь "/", появляется менюшка со списком каталогов и файлов в корне. Так?

кажется я понял, что ты ввиду имеешь. Так вот - это не FAYT. Никоим образом. Для того чтобы пользоваться Qt4-шным автокомплитом - надо читать список.

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

"как сложнее" - это тебе биндинги к Qt надо глянуть. Биндинги к сишным либам как правило элементарны и места для ошибок содержат крайне мало.

>А это не важно. Важно только то, что гуй написан на tk и ничего не тормозит.

вот соберусь с силами и открою в sK1 чертеж какой-нибудь, экспортированный из автокада :)

> Биндинги к сишным либам как правило элементарны и места для ошибок содержат крайне мало.

Ну это, знаешь ли, ещё бабушка надвое сказала...

>> А это не важно. Важно только то, что гуй написан на tk и ничего не тормозит.

> вот соберусь с силами и открою в sK1 чертеж какой-нибудь, экспортированный из автокада :)

И это бабушка сказала также :)

> пока я твой код разгребать буду - посмотри, о чем я говорю.

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

> В трёх Qt-based аппликухах разные диалоги. Видно невооруженным глазом =)

Предлагаю взять xmms, audacious и какой-нибудь easytag. В трёх гтк-шных софтинах разные диалоги =;-)

> Для того чтобы пользоваться Qt4-шным автокомплитом - надо читать список.

Смешно. читать надо в любом случае. хоть ты по listbox бегаешь, хоть из предложенного к combobox выбираешь. Кстати, наличие выделения записей по нажатию первых букв имени во всех listbox из qt3/qt4 есть. Есть она даже для treeview, только она закрытые категории не раскрывает.

>Ну посмотрел. Ну сделал ты через задницу совершенно не нужную вещь. И? Эот не сделало гтк-шный диалог легко используемым из скриптов и не сделало его глобальным в системе.

вот ты чудак. Попробуй аргументировать свой высер про "через задницу"

как из скриптов использовать я тебе рассказывал уже. Проспал?

а этот конкретный пример не про глобальность и прочее - а показывает, как модифицируется gtk через систему модулей. Один из способов. Можешь показать аналогичное для Qt?

>Смешно. читать надо в любом случае. хоть ты по listbox бегаешь, хоть из предложенного к combobox выбираешь.

ты не путай. Сравни набор текста и прыжки с текстовой части клавы на курсоры и обратно. Нету в qt fayt и всё. С чем споришь?

>Кстати, наличие выделения записей по нажатию первых букв

к пятой версии тролли асилят поиск по первым двум буквам? бугага

>Предлагаю взять xmms, audacious и какой-нибудь easytag.

предлагаю взять что-нибудь на мотиф и ужаснуться, что там не gtk-2.0 диалог. А потом пойти и удавиться

>Ну это, знаешь ли, ещё бабушка надвое сказала...

а ты посмотри. А потом сравни с биндингами к плюсовым либам. Потом будешь бабушку газифицировать

>В трёх гтк-шных софтинах разные диалоги =;-)

про easytag ты наврал.

>audacious

про audacius тоже наврал.

т.е. в gtk1 и gtk2 приложениях одинаковый диалог открытия файлов ?

>>что тут думать? В трёх Qt-based аппликухах разные диалоги. Видно невооруженным глазом =)

ты совсем что-ли того ? Во-первых, в qtconfig-qtN диалоги открытия различаются надписью на кнопке 'Open' и двумя надписями слева внизу, возле поля ввода. Во-вторых, в KDE НЕ QFileDialog, а KFileDialog.

Аналогично я могу предъявить претензии почему в xmms один диалог а в Гимп другой ?

> как из скриптов использовать я тебе рассказывал уже. Проспал?

zenity -- это gtk-диалог? бггг

> а этот конкретный пример не про глобальность и прочее - а показывает, как модифицируется gtk через систему модулей. Один из способов. Можешь показать аналогичное для Qt?

Ну отлично, получили вещь в себе. Нах?

> к пятой версии тролли асилят поиск по первым двум буквам? бугага

в qt3 есть хоть по первым 10.

> Нету в qt fayt и всё. С чем споришь?

Есть.

>> Предлагаю взять xmms, audacious и какой-нибудь easytag.

> предлагаю взять что-нибудь на мотиф и ужаснуться, что там не gtk-2.0 диалог. А потом пойти и удавиться

Молодец, Гика, пойди и удавись. Сам-то взял приложения из qt3 и qt4 и бузел, что там диалоги разные :)

> про audacius тоже наврал. про easytag ты наврал.

Рассмотрим подробнее:

xmms -- диалог в стиле gtk-1.0

audacious -- какая-то чёрная хрень.

easytag -- там действительно gtk-2.0

Помнишь, что сделал с собой Томми? ;)

> А потом сравни с биндингами к плюсовым либам.

То, что с плюсовыми биндингами всё ещё хуже, никак не оправдяывает уродство GObject.

Вообще, где биндинги брейнфака к gtk, раз там всё так хорошо с биндингами? ;)