Gtk+ 3 Roadmap

> скоро-скоро, не волнуйся, сможешь ещё потроллить про либы бородатого года

А что там троллить одноразовый софт ?
Сам сюда набежали почесать свое СЧВ и все обсуждение новостей Gnome свети очередному обсасыванию «а вот у нас в Kde ...»

вменяемые люди при разработке будут использовать свежий фреймворк, как ты тут не крутись

А Луна не из чугуна , да.))

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

Видишь ли, в гимпе своя реализация прикрепляющихся панелей. Более централизованное решение называется libgdl.

>> Мне слоган пронравился.

Two level applications - C and <your favorite runtime>

Знаю, я уже так работаю:? ядро C++ и логика ECMAScript. Удобно, блин, и быстро.

> Ну если доки, то понятно. Это уже давно. Причем док по тому же GtkSocket. Будем иметь фишку типо отсоедияющихся табов в Chrome в разных процессах. (не нужно, да?)

И табы отсоединяющиеся в гтк уже миллион лет есть. Не надо думать (особенно всем кутешникам/кедерастам), что эти отделяемые табы изобрели в гугле и, вот, соизволили показать их линуксоидам в своём мегакульном прожекте, ака chrom{e,ium}.

Все проще. Unix-way библиотеки - автономны. Или не автономны если им для работы ДЕЙСТВИТЕЛЬНО нужна другая либа. А DE пусть остаются для десктопа и не надо их превращать в тулкиты. Это не их дело. Это не unix-way. Гномовцы один раз не задумались. Теперь до сих пор чистят код.

Сейчас уже более мене так: GLib отельно. Gnome отдельно, Gtk отдельно, но оба зависят от GLib. У Кдешников ситуация проще судя по вашим словам. Они не задумываются о таком. «Есть в либах KDE - на ура, берем, используем»

> тут ничего не изменишь, не меняя идеологию

так можно поделить пакеты на части и правильно расставить зависимости, чтобы не получалось, как в последней Федоре, что Консоль тянет за собой работоспособное КДЕ))

>> GtkSocket — Container for widgets from other processes

Что-то мне это здорово напоминает... А! Вспомнил! актив-Х и КОМ, вот!

Походу, ты ничего не знаешь ни об одном, ни о втором.

> Потому что цветокоррекция по профилю должна выполняться глобально, а не по воле одного несчастного тулкита :)

Дык я и имел в виду «глобально». Просто не рассматривал другие тулкиты :). Сам я гткшник, вот и говорил про «все гтк программы», а более другие не рассматривал. :)

>> Все проще. Unix-way библиотеки - автономны. Или не автономны если им для работы ДЕЙСТВИТЕЛЬНО нужна другая либа. А DE пусть остаются для десктопа и не надо их превращать в тулкиты. Это не их дело. Это не unix-way. Гномовцы один раз не задумались. Теперь до сих пор чистят код.

Сейчас уже более мене так: GLib отельно. Gnome отдельно, Gtk отдельно, но оба зависят от GLib. У Кдешников ситуация проще судя по вашим словам. Они не задумываются о таком. «Есть в либах KDE - на ура, берем, используем»

Не все библиотеки одинаково автономны. Если библиотека связана с ГУИ - она как минимум будет тянуть за собой свой гуёвый тулкит (одну и более его компонентов).

Я просто привел пример применения )

>А DE пусть остаются для десктопа и не надо их превращать в тулкиты

если я не ошибаюсь, ДЕ должно ингтегрировать приложения, которые в него входят

>> Походу, ты ничего не знаешь ни об одном, ни о втором.

Правда? И чего же я не знаю?

Конечно. Но я не против Qt на своей машине. Это не много и не грязно. Но КДЕ тянуть, нет спасибо. Потом меню чистить. Да и вообще, я говорил о том что DE и тулкит - разные вещи. Не надо делать компоненты в стиле «милая кнопочка» в составе DE. Ибо тянет DE. А если MacOS X или винда. Просить юзера установить Gnome/KDE?

> Видишь ли, в гимпе своя реализация прикрепляющихся панелей.

O_O А в Inkscape более своя реализация? /me просто думал, раз оно в gimp, то и в gimp toolkit, ака gtk, оно есть.

>> если я не ошибаюсь, ДЕ должно ингтегрировать приложения, которые в него входят

А идеальная ДЕ должна интегрировать не только приложения, которые в неё входят, а и ВООБЩЕ ВСЕ приложения end-user уровня. И если уж имеем зоопарк тулкитов на сегодняшний момент - то надо бы его хотя бы друг с другом интегрировать...

Это да.

Может дабавлять к новостям про Gtk|Qt|KDE|Gnome метку типо «срач»?

>> Но КДЕ тянуть, нет спасибо.

Тут видимо косяк в зависимостях допустили дистростроители. Тот же kdelibs, вроде как, в меню ничего не добавляет. Хотя, судя по всему, все этим грешат. Я, вот, ставил OpenSUSE 11.1 ВООБЩЕ без гнома, а через полгодика, поустанавливав/поудаляв пакеты с репов, с удивлением обнаружил у себя вполне работоспособный гном... =)))

Вы пришли под конец и осветили всех своей мудростью. Просьба: или скажите что-то по делу или не мешайте

>> Может дабавлять к новостям про Gtk|Qt|KDE|Gnome метку типо «срач»?

Тогда ВООБЩЕ ко всем более-менее интересным новостям. Особенно - MONO забыл =)

> Но КДЕ тянуть, нет спасибо. Потом меню чистить.

рекомендую ))

http://www.gtk-apps.org/content/show.php/Gnome+Menu+Extended+(Debian+package)...

> А в Inkscape более своя реализация?

А в Inkscape вообще локальная копия старого libgdl, которая даже группировку во вкладки делать не умеет.

Qt3 и Qt4 могут прекрасно уживаться друг с другом

при помощи qt3support - да... а вот qt 4.5 и qt 4.6, например, не всегда совместимы... уже накалывался

> +(Debian+package)...

С вирусом хоть? :)

А как же )

И то дело :)

>> при помощи qt3support - да... а вот qt 4.5

У меня прекрасно и дружно живут на одной тачке Кеды 3.5 и 4.3....

qt 4.5 и qt 4.6, например, не всегда совместимы... уже накалывался

Это да, есть такое. Но «уживать» их особо и не нужно. Было. Раньше. Qt 4.6 какой-то слишком багнутый, жду первого багфикс-релиза, вот...

мож и работает, конечно, но в работе только мешать будет

>>>> GtkSocket — Container for widgets from other processes

Что-то мне это здорово напоминает... А! Вспомнил! актив-Х и КОМ, вот!

Походу, ты ничего не знаешь ни об одном, ни о втором.

Правда? И чего же я не знаю?

Одна вещь заметна сразу: ты считаешь, что ActiveX и COM предназначены для внедрения окон приложений (путаешь с OLE1). На самом деле COM - это объектная модель, а ActiveX - вид компонентов на основе COM.

Чего еще ты не знаешь - ХЗ.

В Debian Thunderbird уже из Ubuntu ... ((

ЩИТО? В Убунте ж всегда был Evo, или не?

> мож и работает, конечно, но в работе только мешать будет

не просто сам proof-of-the-concept очаровал. это не продакшн.

У меня прекрасно и дружно живут на одной тачке Кеды 3.5 и 4.3....

Я настрадался. Внимание, история на Винде. Провел в универе конкурс. Надо было прогу на Qt4 писать. И там была БД через ODBC. Ребята сделали, Qt либы положили, а Qt ODBC драйвер забыли. У них как-то дома работало. Принесли мне -> не работает. Driver not loaded. Я давай ложить драйвер куда надо. Не работает. Удалил все либы. Положил свои с драйвером. Не работает. В Qt ABI не было, нету и не будет. Пересобрал и заработало. Хоть на уровне исходного кода было совместимо. И эта песня была просто с разными билдами Qt. Проконсультировался со знакомым Qtшником. Говорит для бинарной совместимости нужно ПОЛНАЯ идентичность бинарников. Одна версия, один компилятор. Думал что плохо, но такого не ожидал.

Я сам решил не вступать в дискуссию по MS технологиям ибо оффтоп и даже MS от них отвернулась. COM/ActiveX->legacy. Тут выскочили Qtшники с поддержкой. Круто. Апплодирую стоя, поддержка Microsoft legacy technology. О дотнетах не слышали, раз уж вы такие Windows-friendly?

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

Наткнулся на статью когда то. Там человек рассказывал что идея с GObject и C привела к тому что любая Gtk программа, именно бинарник, работает с современным Gtk в том случае если она собрана после 2002 года. Сам не проверял, но впечатляет.

>> при помощи qt3support - да... а вот qt 4.5

У меня прекрасно и дружно живут на одной тачке Кеды 3.5 и 4.3....

я про что и говорю :)

>> qt 4.5 и qt 4.6, например, не всегда совместимы... уже накалывался

Это да, есть такое. Но «уживать» их особо и не нужно. Было. Раньше. Qt 4.6 какой-то слишком багнутый, жду первого багфикс-релиза, вот...

ещё как нужно... часть проектов идёт на 4.5, а часть на 4.6... и от меня не всегда это зависит... приходится держать зоопарк (слава богу нормально можно сделать)

>> На самом деле COM - это объектная модель, а ActiveX - вид компонентов на основе COM.

См. мой пост чуть ниже. Что такое COM я себе замечательно так знаю. А в так возбудившем тебя посте имел в виду именно реализацию COM, т.к. представить себе даже не могу, зачем может быть нужно просто рисование окошка одного приложения в окошке другого.

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

Ну тебе же обьяснили. Плагин в другом адресном пространстве. Ты знаешь разницу между segfault в твоей программе и в чужой?

http://packages.qa.debian.org/i/icedove.html

Ну просто банальная слепота. У нас в универе если не на первой паре, то на второй объяснили разницу в стабильности, надежности и безопасности между fork/pipes и pthreads.

By the way. Хром форкает flash plugin. Вижу здравый смысл

>> Я настрадался. Внимание, история на Винде. Провел в универе конкурс. Надо было прогу на Qt4 писать. И там была БД через ODBC. Ребята сделали, Qt либы положили, а Qt ODBC драйвер забыли. У них как-то дома работало. Принесли мне -> не работает. Driver not loaded.

Ясен пень. Зачем детей плохому учишь? Нативные драйверы юзать нынче не модно? Вот так вот, вся венда: «вот так вот, через какую-то хитрую жопу оно и работает». Так что юникс-вей с его жестким деревом зависимостей - отнюдь не самое худшее решение на этой планете.

И эта песня была просто с разными билдами Qt. Проконсультировался со знакомым Qtшником. Говорит для бинарной совместимости нужно ПОЛНАЯ идентичность бинарников. Одна версия, один компилятор. Думал что плохо, но такого не ожидал.

Это актуально для плагинов Qt, да, я знаю (У Qt собственный кроссплатформенный API для динамического подключения плагинов). Драйверы БД (включая ОДБЦ), поддержка графических форматов и некоторые другие фичи в Qt реализованы как плагины. Внутреннюю реализацию API плагинов в Qt я не ковырял, но то, что подобная хрень имеет место быть - это факт. За удобство (подключение и отключение плагинов «на лету», экспорт классов со всеми свойствами, сигналами и слотами) приходится платить вот такой вот несовместимостью между версиями.

>> Плагин в другом адресном пространстве. Ты знаешь разницу между segfault в твоей программе и в чужой?

А управлять рисуемым плагином - как? Для того, чтоб из этого можно было бы извлекать реальную пользу - нужна двусторонняя связь, т.е. рисуемым в твоём окошке плагином надо бы ещё как-то управлять. Если управление чуть сложнее чем отправка плагину сообщений типа «открыть файл» или «запустить воспроизведение» - то в конце концов приходим к объектной модели, т.е. всё к тому же COM, который является очень, очень, очень толстой реализацией идеи плагинов.

> Ясен пень. Зачем детей плохому учишь?

Не учу, а сложная политическая ситуация. Преподаватель имеет хороший опыт в программировании. И он организатор конкурса. Но тяготеет к 90тым. Придумал задание. В его варианте задания было MFC ))) Пришлось поправить на немного более актуальную тему. Предложил добавить Qt опционально. Gtk отбросил сразу. Студенты, борода еще не выросла. А я студент, в конкурсе не участвую ибо конкурс для популяризации программирования и нужно людей привлечь, а не сделать «Тузик тряпку» участвуя как серьезный Qt программер. Так вот, ближе к делу. Он еще сказал сохранить в MS Access. Хмм.... Ну я забил как бы, если уже такое извращение, то пусть будет ODBC и никаких проблем.

С плагинами в Qt хорошо сделано. Но там просто сложнее наверное. В g* GModule есть. Но так как все на С там все сводится к кроссплатформенной загрузке so/dll с получением адреса функций.

Проконсультировался со знакомым Qtшником. Говорит для бинарной совместимости нужно ПОЛНАЯ идентичность бинарников. Одна версия, один компилятор. Думал что плохо, но такого не ожидал.

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

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

Это ничего необычного. Просто две обычные программы. Два процесса. Хочешь dbus, хочешь gconf (мало ли).

И еще, с современными версиями Qt должны запускаться проги, скомпиленые ещё для 4.2 (кажется тогда они обрели бинарную совместимость) Хотя я не проверял, но точно могу сказать, что проги собранные на 4.4 продолжали работать с 4.6 либами. Там очень даже много сделали для бинарной совместимости с приложениями, но между компонентами Qt бинарной совместимости уже нет, то есть низя qt-gui оставить 4.4 а qt-core поставить от 4.6 Во внутреннее API мы лазили и я примерно представляю, как достигается эта самая бинарная совместимость, собственно там юзается модифицированый pimpl

>> сказал сохранить в MS Access

Точно, извращенец. Это уж совсем 90-е, где-то середина.

С плагинами в Qt хорошо сделано. Но там просто сложнее наверное. В g* GModule есть. Но так как все на С там все сводится к кроссплатформенной загрузке so/dll с получением адреса функций.

Да, а в Qt - весь функционал: сигналы, слоты, т.е. полная взаимосвязь. Очень полезно, например, для оченть больших проектов,чтоб не тянуть сразу всё, а динамически загружать/выгружать нужные модули. И никто не заставляет использовать, вроде как (точно не знаю) нужные плагины (типа драйверов БД) можно как-то линковать статически. Видимо, создавая API плагинов, никто не задумывался о том, что плагины будут собирать одним компилятором и с одной версией Qt, а приложение, эти плагины вызывающее - с другой.

И никто не заставляет использовать, вроде как (точно не знаю) нужные плагины (типа драйверов БД) можно как-то линковать статически

Драйвера БД можно прямо в QtSql загонять, я так и выкручивался на Винде

Ну там все сложно. Почему? Проблема не в Qt, не в Trolltech, не в Nokia. Проблема в С++. Вы думаете зря гномовцы парятся со всеми неудобствами связанными с С? Они бы с радостью перешли на плюсы при условии стандартизированого ABI. Но их подход «идеально правильное техническое решение, какого бы труда это не стоило» оправдывает себя и не имеет таких проблем

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

А как ты себе представляешь вызов плагинов с одним ABI из приложения с другим ABI, в Винде же даже release и debug версии плагинов разные ABI имеют, грабли несусветные. Намучался с этим немало, из за этого часто возникают вопросы «а почему в Кутиме окно добавление протоколов пустое?». Ну нету общего стандарта на ABI, поэтому и не дают грузить плагины, которые имеют разный QT_BUILDKEY, в противном случае, если попытаться его загрузить и пустить, сразу же получим сегфолт. Оно нам надо?

>> Это ничего необычного. Просто две обычные программы. Два процесса. Хочешь dbus, хочешь gconf (мало ли).

Ну, приблизительно - тот же самый COM. С точки зрения юзера - вообще одно и то же, для работы программы X требуется наличие в системе полной версии программы Y (если программа Y - ещё и проприетарная, и за бабло - то вообще супер-весело. 1Ass тому яркий пример, и другое говно, требующее для работы обязательного наличия M$O с его COM-провайдерами). А вообще - лично я никогда не любил идеологию COM и ему подобных.

Одного не пойму: gconf - это ж вроде иерархическая мусорка, по типу реестра, для хранения конфигов. Как с помощью неё вызывать методы одной программы из другой?