Будущее GTK

> В конце концов, на оригинальный GTK+ можно вообще забить :)

Ну да, взять и забить на единственный вменяемый тулкит под LGPL. Чего же нет. Потом забить на Linux и юзать Hurd. А вообще лучше просто взять и забить, и мир сразу станет цветнее. ;-)

Разве? В C++ вполне можно использовать сишный код, LGPL вполне разрешает линковать библиотеку с приложением/библиотекой под другой лицензией... В чём проблемы-то? ;)

> И ради чего?

А то ты не знаешь. Just for fun.

> В чём проблемы-то? ;)

Проблема в том, какя будет лицензия у этого фантастического комбайна. :)

А, здесь речь всё-же шла о замене GTK+ Qt... Тогда нафиг. %)

>Разве? В C++ вполне можно использовать сишный код, LGPL вполне разрешает линковать библиотеку с приложением/библиотекой под другой лицензией... В чём проблемы-то? ;)

проблемы в том, что Qt _в_ _принципе_ неспособно реализовать некоторые возможности gtk

Ну системные сообщения и вызовы от GTK qt 4.1.X уже понимает (написан библиотека обмена событиями ) .Покрайне мере так описывалось в изменениях .

> Разве? В C++ вполне можно использовать сишный код,

Проблема в том, что в сишном коде нужно будет использовать C++'ный код. Нет, даже не так... В коде на произвольном языке с c-style foreign function interface надо будет использовать модифицированный троллями C++'ный код. Но это, кхм, технически решаемая проблема. Нерешаемая проблема в том, что бизнес не хочет отстёгивать денег варяжской компании за использование их самой-лучшей-круче-всех-офигеть-дайте-две библиотеки, когда есть бесплатные аналоги.

Другая проблема trolltech/qt в том, что это продукт одной компании. Такая же проблема у sun/opensolaris. У sun/java тоже такая проблема была, пока одна известная компания не купила другу известную компанию поменьше и не начала активно мейнтейнить параллельную реализацию jvm. Надеюсь, не нужно объяснять, почему залочка на продукте одного вендора - это плохо?

А ещё у меня есть личное наблюдение: QT, в основном, любят студенты, у которых преподаётся курс ООП с использованием C++ (у которого, собственно, и ООП-то не очень ;)

> Ну системные сообщения и вызовы от GTK qt 4.1.X уже понимает (написан библиотека обмена событиями ) .Покрайне мере так описывалось в изменениях .

Это ты так про d-bus?

>В C++ вполне можно использовать сишный код

Не всякий.

> проблемы в том, что Qt _в_ _принципе_ неспособно реализовать некоторые возможности gtk

Ну вот и будет повод расширить Qt. [lol mode off] А какие возможности, интересно знать?

> Проблема в том, какя будет лицензия у этого фантастического комбайна. :)

Если мы собираемся расширять Qt - естественно, GPL. Если активно использовать код из GTK - смешанная лицензия, частично GPL, частично LGPL, с невообразимыми трудностями совмещённый через страшные костыли.

Забавная картинка...

>Ну вот и будет повод расширить Qt.

переписать Qt на сях? Здравая мысль :)

>[lol mode off] А какие возможности, интересно знать?

GTypePlugin и G_OBJECT_CLASS() например ;)

Да вроде не d-bus ,как я прочел . >> и теперь приложения написанный на других библиотеках (GTK) допускаются в системные вызовы qt .Например приложения с библиотекой GTK могут корректно работать с Kicker (панель задач ) .Насколько я понял применяется что то из стандартов freedescop .

>Что значит "бы"? Qt уже умеет :)

Насколько я знаю, там можно сделать GL widget и painter будет знать, как в него праивльно рисовать. А вот переключить всё приложение на GL, IMHO, пока нельзя. Чтобы оно полностью через GL рисовалось

Точно не может??? Что-то я из простого описания не понял, что в них страшного...

>GTypePlugin

Q_DECLARE_INTERFACE, пример в Plug & Paint

>G_OBJECT_CLASS

вся система свойств, сигналов и слотов QObject

> Насколько я знаю, там можно сделать GL widget и painter будет знать, как в него праивльно рисовать.

Да, и фишка в том, что внутри QGLWidget может быть любой Qt виджет. Соответственно, ты можешь всё приложение написать через QGLWidget вместо QWidget, и оно будет работать. Таким образом, если появится возможность и необходимость рисовать всё в OpenGL, в Qt останется переписать только один класс.

А пока можно просто в примерах к libqt4-devel найти приложения, написанные через QGLWidget и посмотреть, как это реально на практике - OpenGL виджеты. Заценить тормоза, опять же, на системах без 3D.

>Q_DECLARE_INTERFACE, пример в Plug & Paint

я бы посоветовал сначала ознакомиться с системой типов glib, а потом фантазировать =)

>вся система свойств, сигналов и слотов QObject

аналогично =)

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

а мужики-то и не знают. и много на этой альтернативе написано?

>Точно не может???

гарантирую. Для реализации системы типов glib в Qt придется Qt переписать в стиле glib, т.е. на сях =)

проблема в том, что Qt написан на плюсах, где кишки ООП _недоступны_ средствами языка

Разворачиваю наезд на 180°. Что можно сделать с использованием GTypePlugin, чего нельзя сделать с Qt'шным Plugins фреймворком?

G_OBJECT_CLASS — аналогично. Что ты не сможешь сделать с помощью Qt object model?

Может хватит троллить, а?

> Для реализации системы типов glib в Qt придется Qt переписать в стиле glib, т.е. на сях

Гтк-шный ооп - феерическое говно. Прекрати вообще выдавать эти кривые костыли за вершину программерской мысли.

>проблема в том, что Qt написан на плюсах, где кишки ООП _недоступны_ средствами языка

То, что недоступно, восполняет qt object model. moc делает всё, что необходимо для работы с объектами qt. Посмотри на QtScript, хотя бы

>Что можно сделать с использованием GTypePlugin, чего нельзя сделать с Qt'шным Plugins фреймворком?

зарегистрировать новый тип, замещающий/модифицирующий оригинальный

>G_OBJECT_CLASS — аналогично. Что ты не сможешь сделать с помощью Qt object model?

G_OBJECT_CLASS(obj)->constructor = my_cool_constructor

>Может хватит троллить, а?

может хватит тупить, а?

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

ты просто очередной тупой анонимус. Иди в жопу

> проблема в том, что Qt написан на плюсах, где кишки ООП _недоступны_ средствами языка

Лапшу с ушей сними, красноглазик. В С++ можно сделать тоже самое гораздо быстрее и лучше, поскольку есть и шаблоны и RAII. Никто такие вещи не делает т.к. смысла в этих костылях нет.

> ты просто очередной тупой анонимус

исходники гтк гарантируют обратное. как им вообще не стыдно такой быдлокод писать?

>зарегистрировать новый тип, замещающий/модифицирующий оригинальный

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

>G_OBJECT_CLASS(obj)->constructor = my_cool_constructor

то же самое

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

Qt'шный ООП в частности и C++'ный ООП в общем - говно. Прекрати выдавать эти кривые костыли за вершину программерской мысли.

> я бы посоветовал сначала ознакомиться с системой типов glib

Кстати, документации по этому вопросу совсем мало, особенно касаемо того, как это реализовано изнутри. Кто сказал, что GNU/Linux плохо докуметированная система? Она отлично документирована на языке Си. =)

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

тебе придется ВЕСЬ Qt на фабриках переписать, чтобы не отрезать от GTK нехилую часть при внедрении в этот самый Qt. Возьмешься? А смысл?

>то же самое

бгг.

> Да, и фишка в том, что внутри QGLWidget может быть любой Qt виджет. Соответственно, ты можешь всё приложение написать через QGLWidget вместо QWidget, и оно будет работать. Таким образом, если появится возможность и необходимость рисовать всё в OpenGL, в Qt останется переписать только один класс.

В gtkmm всё то же самое

>В С++ можно сделать тоже самое гораздо быстрее и лучше, поскольку есть и шаблоны и RAII

шаблоны заработали в рантайме? А RAII тут каким боком?

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

или обычное наследование. в гуи тулките больше и не требуется.

>при внедрении в этот самый Qt

чур меня, чур :) Совершенно разные принципы у библиотек

>или обычное наследование. в гуи тулките больше и не требуется.

ага. А потом наблюдаем в биндингах этого тулкита к тому же питону, как один QEvent превращается....в четыре pyQEvent_blah-blah, потому что иначе как через жопу написать биндинги к плюсам нереально

=)

> шаблоны заработали в рантайме? А RAII тут каким боком?

шаблонами проще сделать рутинные операции которые в си делаются макросами и ручками. а RAII для автоматических addref-release.

>Целый ряд разработчиков во главе с Mirco Muller (Canonical, Ltd) мечтают увидеть отрисовку виджетов полностью на OpenGL,

Это вроде называется "glui". Либа полностью использует opengl для отрисовки. Уже довольно давно существует. На слабых компах довольно сильно тормозит, если интерфейс сложный.

> как один QEvent превращается....в четыре pyQEvent_blah-blah,

во первых он не один, а их целое семейство: QTimerEvent, QMouseEvent, QWheelEvent, QTabletEvent и др. во вторых ты опять пургу несешь. на один С++ класс требуется один питоновский класс.

> шаблоны заработали в рантайме?

Не поверишь - заработали! :-D http://migun.livejournal.com/22664.html

А что за прибор? Для чего предназначен? Интересуюсь всякими девайсами на ARM под линукс, потому спрашиваю Ядро сильно допиливать пришлось? Или какая-то стандартная аппаратная платформа используется?

>>А что за прибор?

Девки довольны =)

>>Для чего предназначен?

Сбор данных

>>Ядро сильно допиливать пришлось?

Только для дисплея, в остальном обрезаный linux-2.6.20 с патчем at91

>>Или какая-то стандартная аппаратная платформа используется?

Нет

>> проблема в том, что Qt написан на плюсах, где кишки ООП _недоступны_ средствами языка

>Лапшу с ушей сними, красноглазик. В С++ можно сделать тоже самое гораздо быстрее и лучше, поскольку есть и шаблоны и RAII

Возникает ощещение, что таких идиотов штампуют на какой-то одной фабрике объектов.

> Возникает ощещение, что таких идиотов штампуют на какой-то одной фабрике объектов.

Кафедры ПМ, ПОВТ, САПР, etc в постсоветской России

>Кафедры ПМ, ПОВТ, САПР, etc в постсоветской России

Не стоит так "массово" заниматься развешиванием ярлыков.

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

О! Еще как перегоним! Клянемся!Клянемся!Клянемся!

> Парсеры XML в QT неплохи, а интернациализация задумана и реализована блестяще, так что про жопы тут не надо.

1) множественные формы появились только в 4.4
2) создать программу, которая не работает с кириллицей - до сих пор как нехрен делать.

> Лучше вообще-то сделать отрисовку через OpenGL на уровне X-сервера. Имхо.

Кстати, да. На днях обсуждали cairo-glitz с Карлом Вортом, и тоже считает, что лучше X-сервер чинить.

>1) множественные формы появились только в 4.4

Главное, что появились :)

>2) создать программу, которая не работает с кириллицей - до сих пор как нехрен делать.

Ну-у-у-у... Собственно говоря, на создание качественного продукта уходит много времени и сил, а склепать, пардон, говно -- как нехрен делать ;)