Вышел D-Bus 1.0 «Blue Bird»

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

А уж на DCOM сколько держится! Вот интересно, а с распространением D-Bus развитие пойдёт тем же путём (чур-меня) что и оффтопик? Всякие там активные компоненты а-ля M$.

Скажите, а зависимость от glibc Вас не очень напрягает? В плечах не жмет?

>И что она добавляет к этому вопросу?%)

http://www.linux.org.ru/jump-message.jsp?msgid=1656219#1657636

Дада, я уже осознал. КДЕ милостиво снизошел до использования общего кода с fd.o;) В общем, интеграция - безусловно, дело полезное и требует усилий с обеих сторон. Только надо помнить, что этот дерибас был сделан и изначально использовался в гноме... А мой вопрос был и остается - какая из технологий, _зародившихся_ в КДЕ, перелезла на fd.o. Впрочем, отвечать не обязательно...

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

1. DCom (COM), RPC - было 2. Indigo - развитие

пионер, блин...

>Дада, я уже осознал. КДЕ милостиво снизошел до использования общего кода с fd.o;)

Есть подозрение, что D-Bus в каком-то виде inspired by DCOP. В файле AUTHORS, во всяком случае, есть народ и из kde.org, и с gtk.org, и с gnome.org

> Вот интересно, а с распространением D-Bus развитие пойдёт тем же путём (чур-меня) что и оффтопик? Предложите что-нть получше... В венде RPC и DCOM используются системными службами, файрволами и тому подобной фигней, однако RPC относительно плохо документировано и закрыто, поэтому разработчики не из М$ редко юзают RPC. Как правило, для связи между прогами используются самопальные системы мультиколесных велосипедов или именованные IPC, например.

> какая из технологий, _зародившихся_ в КДЕ, перелезла на fd.o. Впрочем, отвечать не обязательно...

Я, возможно, не владею историей вопроса, но разве D-BUS - это не "мы тоже хотим DCOP, но нас не устраивает лицензия"?

KDE-шные штуковины все завязаны на Qt, поэтому GPL, поэтому общему десктопу не очень подходят - не позволят, скажем, сделать FreeDesktop compilant CDE ;-), ежели кому вдруг приспичит.

Идеологически - да, он inspired. Где-то даже в явном виде об этом говорится (то ли в доках, то ли на сайте). Да, КДЕшники работают над кодом fd.o (если б fd.o тянули одни гномовцы - один этот факт поставил бы крест на интеграции, я думаю). Но я ж не об этом изначально. Я о том, что сам по себе код из стека КДЕ/Qt никто никогда никуда не вытащит, скорее всего (CMIIW). Потому как первая же строка с использованием Qt - это довольно мощный platform lock с очень дорогой зависимостью от Qt (как по размеру, так и по лицензии).

Вот именно об этом я и говорю: "завязка на Qt -> невозможно использовать в общем десктопе".

> Ну вот. Эта новость к вопросу svu "А что кдешники сделали для всех?" )))

Кстати, а что?

Может, уже завяжем?;)

> PS: На ближайших выходных будет метеорный дождь беспрецендентной интенсивности.

ужоснах... ждём больших кратеров в кремниевой долине? уж теперь-то венде капец

>Я о том, что сам по себе код из стека КДЕ/Qt никто никогда никуда не вытащит, скорее всего (CMIIW)

Копипастом - конечно нет. Однако Qt/KDE вносит неслабый contribution в неявном виде. Взять тот же D-Bus - одна из фишек его в том, что у технологии нет явно заданного API, в отличии от корбы, например.

В итоге мы имеем такую картинку: API для работы с D-Bus заточены под конкретный toolkit, и используется "родным" для конкретного случая образом - например, в Qt его засунули в общую схему сигналов/слотов, и, таким образом, интерфейс D-Bus в работе мало чем отличается от какого-нибудь QProcess или QTimer. Думаю, что в GTK+ или Mono картинки похожие - самого D_Bus "не видно" больше необходимого.

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

да, положа руку на сердце, и копипаст имеется :) на фридесктоп лежит Introduction to D-Bus, взятое из документации Qt :)

> Скажите, а зависимость от glibc Вас не очень напрягает? В плечах не жмет?

напрягает! жмет! что случилось с dbus-binding-tool (glib/dbus-binding-tool, бывшая dbus-glib-tool)? куда она делась из репозитория? теперь не могу собрать PolicyKit!! а без polkit'а hal не собираеццо (на --disable-policy-kit уже кладёт) :(

> Эта новость к вопросу svu "А что кдешники сделали для всех?" )))

Они сделали очень важную вещь: не стали изобретать велосипед! ;-)

.. и перешли сразу к изобретению огня и колеса;)

>. и перешли сразу к изобретению огня и колеса;) KDE-шники придумывают, испытывают и быстро внедряют новые идеи, а GNOMEры их потом медленно переписывают на идеологически правильном макроассемблере C ;)

... с макоассемблера, которому приснилось, что он ОО язык;)

Что-то я сегодня слишком пятничный;)

> напрягает! жмет! что случилось с dbus-binding-tool (glib/dbus-binding-tool, бывшая dbus-glib-tool)? куда она делась из репозитория? теперь не могу собрать PolicyKit!! а без polkit'а hal не собираеццо (на --disable-policy-kit уже кладёт) :(

http://www.freedesktop.org/wiki/Software_2fDBusBindings

> http://www.freedesktop.org/wiki/Software_2fDBusBindings

оо, спасиб! я искал что-то похожее в cvs (через webcvs), а оно оказывается только через git доступно, а его у мну нету, то даже не посмотрел... пошел читать tfm по git'у :)

например, http://www.linux.org.ru/view-message.jsp?msgid=971832 ну и естественно, KDE, QT :)

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

>Я о том, что сам по себе код из стека КДЕ/Qt никто никогда никуда не вытащит, скорее всего (CMIIW).

Тебе для того, чтобы считать, что что-то пришло с KDE, обязательно нужно вытаскивать оттуда куски кода? Просто алгоритмы и принцип работы уже не катит?

>Ну и ко всему прочему, я не думаю, что кутейщики не закомитили ничего в основной проект, помимо своей интеграции...

А ты не думай, ты проверь кто что закоммитил.

И еще подумай, что у qt-шников опыт работы над аналогичным компонентом для разных платформ несколько больше, чем у гномеров.

Алгоритмы и способ работы - безусловно, очень важная контрибуция. Просто если кто-то уже написал (и, главное, отладил) работающий код - зачем его переписывать заново? Обычно это признак того, что что-то не так в изначальной реализации (чаще всего - неправильная технология, но могут быть и другие причины). И намек на то, что на будущее этой цепочкой лучше б не пользоваться (дабы не пришлось переписывать еще раз).