Dbus что это

D-Bus (Русский)

Состояние перевода: На этой странице представлен перевод статьи D-Bus. Дата последней синхронизации: 23 декабря 2021. Вы можете помочь синхронизировать перевод, если в английской версии произошли изменения.

D-Bus — это система межпроцессного взаимодействия, реализующая шину сообщений. Она состоит из демона, который может работать как на уровне всей системы, так и для каждого пользовательского сеанса в отдельности, и набора библиотек, позволяющих приложениям использовать D-Bus.

Пакет dbus устанавливается автоматически как зависимость systemd . Шины для пользовательских сеансов запускаются автоматически.

Альтернативные реализации

dbus-broker

dbus-broker — прозрачная замена libdbus, цель которой «обеспечить высокую производительность и надежность при сохранении совместимости с эталонной реализацией D-Bus». [1]

Для запуска dbus-broker в качестве системной шины сперва отключите службу dbus.service , а затем включите службу dbus-broker.service .

Для запуска dbus-broker в качестве пользовательской шины включите пользовательскую службу dbus-broker.service .

Чтобы задействовать его для всех пользователей, включите его с опцией —global :

# systemctl --global enable dbus-broker.service

Перезагрузитесь для применения изменений.

Советы и рекомендации

Переопределение службы dbus

Вы можете переопределить службы dbus в каталоге ~/.local/share/dbus-1/services .

Если служба уже запущена, переопределение не сработает; необходимо убить существующий процесс службы.

Отладка

• D-Feet — Простой в использовании графический инструмент отладки D-Bus. Можно использовать для проверки интерфейсов D-Bus запущенных программ и вызова методов на этих интерфейсах.

• QDbusViewer — Графический отладчик D-Bus. Можно использовать для проверки служб D-Bus и вызова их методов.

Таже можно использовать команду busctl(1) , которую предоставляет systemd.

Смотрите также

• https://freedesktop.org/wiki/Software/dbus/
• https://freedesktop.org/wiki/IntroductionToDBus/

Retrieved from «https://wiki.archlinux.org/index.php?title=D-Bus_(Русский)&oldid=740584»

Что такое Dbus

Если вы достаточно давно пользуетесь операционной системой Linux, то, наверное, уже не раз слышали о сервисе DBus. Он фигурирует в различных логах программ, инструкциях по настройке системы, а также вы можете видеть сервис DBus-daemon, который непонятно зачем загружается при старте системы.

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

Что такое Dbus?

Dbus или Desktop Bus — это система, которая используется в основном в операционной системе Linux для того, чтобы различные приложения и сервисы могли общаться между собой. Но с помощью Dbus могут взаимодействовать не только приложения, но и пользователи с приложениями.

По сути, DBus состоит из управляющего демона, API для языков программирования, с помощью которых приложения могут взаимодействовать с системой и консольного клиента.

Каждое приложение, которое хочет работать с DBus, должно зарегистрировать свой сервис в демоне DBus. Поскольку все приложения и сервисы могут беспрепятственно обмениваться сообщениями, этот способ еще называется шина DBus. На шине каждое приложение имеет свой адрес, а каждое сообщение имеет своего отправителя и адресата. Приложение может обмениваться сообщениями даже не с одним, а несколькими приложениями одновременно. Каждое приложение может отправлять сообщения и прослушивать входящие.

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

Обычно Dbus создает две шины или области, в которых программы могут обмениваться сообщениями. Это системная шина — для системных сервисов. Ее главная задача — доставка сообщений об изменении состояния оборудования. Вторая шина сессионная, создается отдельно для каждого пользователя и позволяет приложениям, запущенным от его имени взаимодействовать между собой.

Объекты Dbus

Каждое приложение, которое использует Dbus, регистрирует свой объект, а также может регистрировать несколько интерфейсов. Когда объекту отправляется сообщение, его получает и приложение. У каждого объекта уникальное имя. Оно похоже на путь в файловой системе. Чтобы имя каждого объекта было уникальным в нем используется префикс разработчика, например, /org/kde или /com/redhat.

Путь объекта DBus состоит из трех частей:

• Имя сервиса;
• Имя объекта;

Несколько примеров объектов:

• org.freedesktop.NetworkManager
• org.freedesktop.UDisks
• org.freedesktop.DisplayManager
• org.kde.plasmashell

Части имени объектов разделены точкой. Каждый объект имеет один или несколько интерфейсов, которым можно отправлять сообщения.

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

• /org/mpris/MediaPlayer2/Player (org.mpris.MediaPlayer2.VLC)
• /org/PluseAudio/ServerLookup1 (org.PluseAudio1)

Сообщения Dbus

Сообщения Dbus это тоже довольно сложная тема. Они бывают четырех разных типов. Это вызовы методов, результаты вызовов, сигналы и ошибки. Dbus проектировался для использования в первую очередь в программах, поэтому и были реализованы такие сложные структуры. Когда осуществляется вызов метода, программа должна обработать данные и потом в ответном сообщении вернуть результат (результат выполнения) или ошибку.

Доступные объекты Dbus

Большинство доступных объектов Dbus описаны на сайте freedesktop.org. Но лучший способ узнать какие сервисы поддерживает система — это воспользоваться программой qdbusviewer. В окружении рабочего стола kde она поставляется по умолчанию, в Gnome и других ее можно установить из пакета qttools5-dev-tools:

sudo apt install qttools5-dev-tools

Запустив программу через главное меню вы увидите вот такое главное окно:

Здесь вы можете увидеть на левой панели список доступных объектов, на правой — пути к интерфейсу внутри объекта и методы. Внизу консоль, в которую выводится информация об успешности ваших действий.

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

Как использовать Dbus?

Обращаться к сервисам Dbus можно с помощью консольной утилиты dbus-send. Рассмотрим ее синтаксис:

$ dbus-send опции —dest адрес_объекта интерфейс метод параметры

• опции — настраивают общее поведение утилиты;
• адрес_объекта — объект, которому мы собираемся отправлять сообщение;
• интерфейс — интерфейс объекта, который получит сообщение;
• метод — метод интерфейса, который будет вызван, или сигнал;
• параметры — дополнительные параметры, если они нужны.

Рассмотрим опции утилиты:

• —system — использовать системную шину для отправки сообщений;
• —session — использовать сессионную шину;
• —dest — объект, которому будет отправлено сообщение;
• —print-reply — напечатать ответ;
• —reply-timeout — таймаут ожидания ответа;
• —type — тип сообщения, может быть signal, method_call, error, method_result.

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

Вы уже знаете, как и где искать нужные вам интерфейсы, а теперь рассмотрим пару примеров отправки сообщений Dbus.

Получаем список сетевых адаптеров NetworkManager:

dbus-send —system —print-reply —reply-timeout=120000 —type=method_call —dest=’org.freedesktop.NetworkManager’ ‘/org/freedesktop/NetworkManager’ org.freedesktop.NetworkManager.GetDevices

Что здесь происходит? Мы сообщаем программе, что хотим видеть ответ, тип сообщения — вызов метода, объект org.freedesktop.NetworkManager, интерфейс /org/freedesktop/NetworkManager, и метод org.freedesktop.NetworkManager.GetDevices

Включим музыку в плеере VLC:

dbus-send —print-reply —dest=org.mpris.MediaPlayer2.vlc /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player.Play

Поставим на паузу:

dbus-send —print-reply —dest=org.mpris.MediaPlayer2.vlc /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player.Pause

Здесь org.mpris.MediaPlayer2.vlc — объект, интерфейс — /org/mpris/MediaPlayer2, метод — org.mpris.MediaPlayer2.Player.Pause

Методы могут получать параметры, например, перемотаем наш трек на несколько секунд:

dbus-send —print-reply —dest=org.mpris.MediaPlayer2.vlc /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player.Seek int64:10000000

Узнать тип переменной можно тоже с помощью qdbusviewer. Кликните по методу правой кнопкой и выберите Call, в открывшемся диалоговом окне будет предложено ввести значение переменной, а также указан ее тип.

Кроме методов, здесь есть переменные. Понять с чем мы имеем дело, методом или переменной можно тоже с помощью qdbusviewer. Для методов будет написано method, для переменных property. Но посмотреть значение переменной не так просто, для этого используется такая конструкция:

dbus-send —print-reply —dest=org.mpris.MediaPlayer2.vlc /org/mpris/MediaPlayer2 org.freedesktop.DBus.Properties.Get string:org.mpris.MediaPlayer2.Player string:Volume

Вместо того чтобы обратиться напрямую к переменной интерфейса, мы используем метод org.freedesktop.DBus.Properties.Get объекта /org/mpris/MediaPlayer2 и передаем ему две строки. Имя интерфейса и имя переменной. Данный пример показывает, как посмотреть текущую громкость VLC.

Установить значение переменной еще сложнее. Для этого используется метод org.freedesktop.DBus.Properties.Set:

dbus-send —print-reply —dest=org.mpris.MediaPlayer2.vlc /org/mpris/MediaPlayer2 org.freedesktop.DBus.Properties.Set string:org.mpris.MediaPlayer2.Player string:Volume variant:double:1.1

Пример изменяет громкость воспроизведения VLC. Этот метод принимает уже три параметра две уже знакомые нам строки и новое значение переменной. Значение переменной имеет тип variant и ему нужно задать нужный тип переменной, в нашем случае нужна double. Посмотреть какой тип переменной нужен вам можно в qdbusviewer, кликните по переменной правой кнопкой мыши и нажмите Set Value. Здесь кроме поля ввода значения вы увидите нужный тип переменной.

Выводы

Теперь вы знаете не только что такое Dbus, но и все необходимые основы, чтобы использование Dbus было для вас достаточно простым в вашей системе и вы могли применять его на полную для управления своими программами. Нашли интересную команду Dbus, которая будет полезна другим пользователям? Напишите в комментариях!

Управление Linux десктопом через D-Bus

Оригинал: Control Your Linux Desktop with D-Bus
Автор: Koen Vervloesem
Дата публикации: 01 Января 2011
Перевод: Максим Хвощ
Дата публикации перевода: 28 января 2013 г.

Используя D-Bus, вы можете персонализировать и автоматизировать ваш десктоп.

Каждая современная Linux среда рабочего стола использует D-Bus, систему, позволяющую программным приложениям общаться друг с другом. Благодаря D-Bus, ваш десктоп может быть настроен точно так, как вы хотите. В этой статье я привожу примеры некоторых возможностей D-Dus. Будьте готовы к модификации вашего десктопа.

D-Bus (Desktop Bus) — система межпроцессного взаимодействия (IPC system), которая позволяет приложениям в операционной системе общаться друг с другом. Создатели D-Bus построили свою систему с нуля, но находились под сильным влиянием системы DCOP (Desktop COmmunication Protocol) из среды KDE. В настоящее время D-Bus используется везде — в KDE 4 DCOP уступила D-Bus, а GNOME переходит на D-Bus вместо своей собственной системы Bonobo. Так что D-Bus стал независимым от десктопной среды механизмом межпроцессорного взаимодействия. ПО, которое использует D-Bus, незаметно интегрируется в ваш десктоп, независимо от того, какую среду вы используете. D-Bus является частью кросс-платформенного проекта freedesktop.org, главным участником которого является Red Hat.

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

D-Bus не разрешает прямую коммуникацию между процессами, а работает через шину. Системная шина обеспечивает маршрутизацию сообщений между процессами через себя, таким образом, процессы могут взаимодействовать с несколькими приложениями одновременно. Каждое приложение может посылать сообщения на шину или реагировать на события, получаемые через шину.

Обычно, D-Bus создает две шины: привилегированную системную шину и сессионную шину. Системная шина позволяет осуществлять широковещательное взаимодействие между процессами, имеющими необходимые права доступа. Ее главное назначение — доставка событий от HAL (Hardware Abstraction Layer) к процессам, работающим с аппаратными событиями. Таким аппаратным событием может быть обнаружение нового аппаратного устройства, или изменение в очереди печати. Вторая шина — сессионная, создается во время авторизации, и с ее помощью будут общаться приложения, с которыми работает пользователь.

Работа с D-Bus

Каждое приложение, работающее с D-Bus, располагает какими-то объектами, которые в основном мапируются на внутренние объекты GObject, C++ или Python. Одно приложение может послать сообщение определенному объекту из другого приложения. К каждому D-Bus объекту мы обращаемся через уникальное имя, которое выглядит как путь файловой системы. Для обеспечения уникальности имен, каждое имя D-Bus объекта обычно имеет префикс, специфичный для разработчика, например /org/kde или /com/redhat . В языке программирования Java для этих целей используются имена пакетов (например, org.sun ). D-Bus путь состоит из трех частей: имя сервиса, путь к объекту и интерфейс (я приведу примеры чуть позже в этой статье).

Итак, как же можно использовать D-Bus в своем собственном приложении? Основной API написан на С довольно низкого уровня. Он не задумывался для использования программистами приложений. Различные языки программирования и среды разработки, такие как GLib, Qt, Python, Ruby, Perl и Mono имеют надстроенные над этим API связующие слои. Я не буду углубляться в С или GLib (основаная библиотека в GNOME), но я приведу несколько примеров, написанных на скриптовых языках Python и Ruby, а так же примеры скриптов командной оболочки.

Какие приложения используют D-Bus?

На сайте проекта reedesktop.org имеется неполный список приложений, использующих D-Bus, и имена на шине для каждого приложения. Кстати, вы сами можете найти имена на шине D-Bus, используя некоторые интересные инструменты. Например, Qt имеет графический D-Bus браузер — qdbusviewer (Рисунок 1). В Ubuntu вы можете найти это приложение в пакете qt4-dev-tools . Несмотря на то, что оно является частью KDE, это приложение прекрасно работает и в других средах, включая GNOME.

Рисунок 1. QDBusViewer работающий в GNOME

Работая в qdbusviewer, вы видите две вкладки: Сессионная Шина и Системная Шина. В каждой вкладке левая панель показывает список имен сервисов. Если нажать на имя сервиса, то в правой панели появится информация о сервисе, список доступных методов и сигналов. Например, если вы нажмете на сервисе org.freedesktop.PowerManagement , и далее перейдете в правой панели вниз по иерархии — org/freedesktop/PowerManagement/ , то вы пройдете две части пути D-Bus: org.freedesktop.PowerManagement в левой панели является именем сервиса, а org/freedesktop/PowerManagement в правой панели является путем до объекта.

Путь до объекта в правой панели имеет еще одну последнюю часть — три так называемых интерфейса: org.freedesktop.DBus.Introspectable , org.freedesktop.DBus.Properties и org.freedesktop.PowerManagement . Каждый интерфейс реализует какие-то методы и сигналы. Это то, с чем вы можете взаимодействовать. Здесь мы заинтересованы в интерфейсе org.freedesktop.PowerManagement , он реализует действия связанные с управлением питанием. Нажав на него, мы видим список из всех доступных методов и сигналов. Если мы нажмем на метод Suspend, то компьютер заснет, и проснется только после нажатия кнопки питания.

Некоторые методы, такие как Shutdown, Reboot, Hibernate и Suspend, осуществляют действия, а другие методы выдают вам информацию о системе. Например, объект org.freedesktop.PowerManagement реализует такие методы как GetLowBattery, GetOnBattery, CanShutdown, и т.д. Если ваша система (лэптоп) работает от батареи, имеющей достаточный заряд, то нажимая на GetOnBattery, мы получаем «Arguments: true», а при нажатии на GetLowBattery, ответ — «Arguments: false».

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

Если вы являетесь поклонником командной строки, то вам не нужно запускать qdbusviewer. Приложение qdbus, работающее из командной строки, предоставляет точно такую же информацию. Если вы запустите qdbus в терминале, то увидите список сервисов, доступных на сессионной шине. Если вы запустите его с флагом —system, то увидите сервисы, доступные системной шине. Если вы хотите узнать, какие объекты содержит сервис, запустите, например, следующую команду:

$ qdbus org.freedesktop.PowerManagement / /org /org/freedesktop /org/freedesktop/PowerManagement /org/freedesktop/PowerManagement/Backlight /org/freedesktop/PowerManagement/Inhibit /org/freedesktop/PowerManagement/Statistics

Для того что бы узнать, какие интерфейсы реализованы в объекте /org/freedesktop/PowerManagement , используйте:

$ qdbus org.freedesktop.PowerManagement \ /org/freedesktop/PowerManagement

Мы получим тот же самый список из методов и интерфейсов, что мы видели в qdbusviewer. Например, строку:

method bool org.freedesktop.PowerManagement.GetOnBattery()

bool означает, что этот метод возвращает булеву величину, со значением true или false. Если метод не возвращает величину, например org.freedesktop.PowerManagement.Suspend() , то вместо bool используется void.

Также qdbus позволяет нам вызывать эти методы напрямую. Например, если мы хотим вызвать метод Suspend, выполняем:

$ qdbus org.freedesktop.PowerManagement \ /org/freedesktop/PowerManagement \ org.freedesktop.PowerManagement.Suspend

Работаем с D-Bus из командной строки

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

Я уже упомянул первый способ работы с D-Bus: использование KDE программ qdbusviewer и qdbus. Если вы не работаете в KDE, то можете использовать программы командной строки dbus-send и dbus-monitor, для отсылки и мониторинга D-Bus сообщений, соответственно. Например, вы можете отправить систему в спящий режим, следующей командой:

$ dbus-send --dest=org.freedesktop.PowerManagement \ /org/freedesktop/PowerManagement \ org.freedesktop.PowerManagement.Suspend

Как мы видим, dbus-send вызовы практически идентичны вызовам qdbus. Единственное различие — это необходимость использовать —dest параметр для имени сервиса. Теперь давайте взглянем на что-нибудь новенькое. Если вы смотрите в своем браузере длинное видео на YouTube, то может активизироваться скринсейвер, так как Flash плагин не взаимодействует с остальной системой. С помощью D-Bus мы можем остановить это раздражающее поведение. Вот и волшебная команда:

$ dbus-send --print-reply \ --dest=org.gnome.ScreenSaver / \ org.gnome.ScreenSaver.Inhibit \ string:"YouTube" \ string:"Inhibit Screensaver"

С помощью этой команды мы вызываем Inhibit метод интерфейса org.gnome.ScreenSaver , с двумя аргументами. Первый аргумент — это имя приложения. Здесь я использую “YouTube”, но это может быть любое имя. Второй аргумент — это причина — остановка скринсейвера. dbus-send ожидает, что каждому аргументу будет предшествовать его тип (string, boolean, int16 и т.д.). В этом примере оба аргумента имеют строковой тип. Также я использую аргумент —print-reply потому, что мне нужно ответить на команду: Inhibit метод возвращает uint32 число, которое работает как куки, идентифицируюя запрос на остановку скринсейвера. Если мы хотим вновь запустить скринсейвер, то мы должны переслать этот куки в качестве аргумента:

$ dbus-send --dest=org.gnome.ScreenSaver / \ org.gnome.ScreenSaver.UnInhibit \ uint32:1234567890

С помощью этих двух команд, мы можем создать свой собственный скрипт командной оболочки для скринсейвера. Примечание: во время запуска первой команды вы должны сохранить куки в переменную или в файл, а затем заменить значение куки в команде, что выше.

Если вы отлаживаете D-Bus скрипт или наблюдаете за методами и сигналами других D-Bus приложений, то программа командной строки dbus-monitor очень вам в этом поможет. Просто запустите ее через терминал, и вы увидите всю D-Bus активность. dbus-monitor полезен для просмотра D-Bus активности в реальном времени. Если с вашей системой что-то происходит, например пропадает сеть, то на выходе dbus-monitor вы можете видеть как это сообщение поступает на шину D-Bus. Таким образом вы можете узнать какие сигналы или методы должны использоваться для работы с тем или иным событием.

dbus-monitor так же позволяет вам указать ряд выражений, определяющих за чем вы хотите наблюдать, например:

$ dbus-monitor --system "interface='org.freedesktop.NetworkManager'"

С помощью этого вы сможете наблюдать за всеми NetworkManager событиями . Я использовал аргумент —system потому, что NetworkManager использует системную шину.

Пишем скрипт для чтения Liferea ленты

Liferea лента имеет маленький, но интересный набор методов для работы с D-Bus. Наиболее интересный метод — это Subscribe, который позволяет вам добавить к Liferea поток из другого приложения. Одно из приложений, пользующиеся этим — FeedBag, расширение для Firefox, которое изменяет кнопку потока в адресной строке браузера: если вы нажимаете на кнопку, то подписка добавляется к Liferea, а не к Live Bookmarks. Работает FeedBag через вызов метода FeedBag org.gnome.feed.Reader.Subscribe . Тоже самое вы можете сделать и из терминала:

$ feed="http://feeds2.feedburner.com/linuxjournalcom?format=xml" $ dbus-send --dest=org.gnome.feed.Reader \ /org/gnome/feed/Reader \ org.gnome.feed.Reader.Subscribe \ string:"$feed"

Liferea предоставляет скрипт, который делает точно тоже самое, но еще умеет обрабатывать ошибки.

Также, через D-Bus Liferea предоставляет некоторую информацию, которая может оказаться полезной если вы используете альтернативный оконный менеджер, не имеющий области уведомления для Liferea. Вы можете сами сварганить вашу собственную систему оповещения — просто запросите число новых и непрочитанных записей в Liferea и покажите выходные данные:

$ dbus-send --print-reply \ --dest=org.gnome.feed.Reader \ /org/gnome/feed/Reader \ org.gnome.feed.Reader.GetNewItems $ dbus-send --print-reply \ --dest=org.gnome.feed.Reader \ /org/gnome/feed/Reader \ org.gnome.feed.Reader.GetUnreadItems

Без клавиатуры

Если вы хотите выполнить более сложные задания, чем вызов отдельных методов, то вы можете написать скрипт командной оболочки, содержащий dbus-send команды, или используйте язык более высокого уровня, для упрощения задачи. Существуют D-Bus привязки для Python, Ruby и Java языков.

В следующем примере, я реализую скрипт на Python, который меняет ваш статус в Pidgin на “Away from keyboard”, при активизации скринсейвера. Здесь имеются два аспекта D-Bus: скрипт ждет сигнала от скринсейвера, и затем он вызывает метод в Pidgin. Скрипт показан в листинге 1.

Листинг 1. pidgin_screensaver.py

#!/usr/bin/env python def pidgin_status_func(state): obj = bus.get_object("im.pidgin.purple.PurpleService", "/im/pidgin/purple/PurpleObject") pidgin = dbus.Interface(obj, "im.pidgin.purple.PurpleInterface") status = pidgin.PurpleSavedstatusFind("afk") if status == 0: status = pidgin.PurpleSavedstatusNew("afk", 5) if state: pidgin.PurpleSavedstatusSetMessage(status, "Away from keyboard") pidgin.PurpleSavedstatusActivate(status) import dbus, gobject from dbus.mainloop.glib import DBusGMainLoop dbus.mainloop.glib.DBusGMainLoop(set_as_default=True) bus = dbus.SessionBus() bus.add_signal_receiver(pidgin_status_func, dbus_interface="org.gnome.ScreenSaver", signal_name="ActiveChanged") loop = gobject.MainLoop() loop.run()

Давайте разберем этот скрипт. Функция pidgin_status_func устанавливает ваш статус в Pidgin. Она получает объект im/pidgin/purple/PurpleObject и интерфейс im.pidgin.purple.PurpleInterface из сессионной шины. Далее, вызывается метод интерфейса. Он создает новый “saved status” тип, после проверки существования типа статус с именем “afk” (“afk” означает “Away From Keyboard”, и 5 — это вид “away” статуса).

Далее функция проверяет переменную state, которая является аргументом функции pidgin_status_func (я объясню, что означает этот аргумент далее). Если аргумент правдив, то сообщению нового статуса “afk” присваивается значение “Away from keyboard”, и статус активируется. В результате Pidgin показывает ваш статус как “afk», с сообщением “Away from keyboard”.

Теперь мы должны вызвать эту функцию вместе с активизацией скринсейвера. Поэтому, запускаем dbus.mainloop и соединяемся к сессионной шине. Далее добавляем приемник сигнала, который слушает сигнал ActiveChanged от интерфейса org.gnome.ScreenSaver . Если/когда сигнал срабатывает, он вызывает функцию pidgin_status_func . Так как сигнал ActiveChanged имеет булев аргумент, обозначающий текущее состояние заставки (1 — активная, 0 — не активная), то мы используем только один аргумент (state) в функции pidgin_status_func . Для постоянного прослушивания запускаем бесконечный цикл, работающий пока работает скрипт.

Pidgin имеет очень обширный D-Bus интерфейс; вы можете делать с помощью него практически все. Пусть этот пример послужит вам вдохновением для создания каких-нибудь креативных задач в Pidgin!

Проигрывание с помощью D-Bus

Давайте посмотрим на другой пример, на этот раз на Ruby. Мы создадим скрипт, который будет показывать текущую песню, играющую в Rhythmbox, вместо вашего статуса в Pidgin (Листинг 2).

Листинг 2. pidgin_rhythmbox.rb

#!/usr/bin/env ruby require 'dbus' bus = DBus::SessionBus.instance rhythmbox = bus.service("org.gnome.Rhythmbox") player = rhythmbox.object("/org/gnome/Rhythmbox/Player") player.introspect player.default_iface = "org.gnome.Rhythmbox.Player" pidgin = bus.service("im.pidgin.purple.PurpleService") purple = pidgin.object("/im/pidgin/purple/PurpleObject") purple.introspect purple.default_iface = "im.pidgin.purple.PurpleInterface" player.on_signal("playingUriChanged") do |uri| status = purple.PurpleSavedstatusFind("rhythmbox").first if status == 0 status = purple.PurpleSavedstatusNew("rhythmbox", 2).first end purple.PurpleSavedstatusSetMessage(status, uri.to_s) purple.PurpleSavedstatusActivate(status) end

Здесь мы видим команды такого же типа, как и в скрипте на Python: начинаем D-Bus сессию, определяем D-Bus сервис, объекты и интерфейс, и определяем приемник сигнала. Цикл постоянно работает для прослушивания D-Bus сигнала.
Конечно, все это можно немного привести в порядок. Например, на данный момент, в качестве статусного сообщения мы показываем только путь к файлу песни. Я предоставляю вам возможность самим заменить путь к файлу на соответствующий ID3 тег.

Заключение

Теперь, когда вы знаете как выполнять D-Bus запросы и как обрабатывать D-Bus сигналы, вы можете заняться автоматизированием заданий на вашем десктопе. Если вы опытный Linux пользователь, то D-Bus точно должен быть в вашем арсенале.
D-Bus содержит намного больше, чем я могу вам показать в этой статье, но с помощью qdbusviewer, qdbus, dbus-send и dbus-monitor, вы сможете освоить остальные возможности сами. Если вы хотите реализовать более сложные задачи по автоматизации, используя D-Bus, то хорошими помощниками вам могут стать языки Python и Ruby. Рассмотрите учебные пособия, упомянутые в приложении, и далее просто дайте волю своей фантазии.
Если вы разработчик программного обеспечения, то раздел, который мы не рассмотрели здесь, — это регистрация сервиса. Эта другая сторона рассказа о D-Bus. Если вы регистрируете сервис, то с помощью D-Bus вы можете предоставлять объекты для других приложений.

Приложение

Koen Vervloesem — с 2000-х — журналист-фрилансер, пишущий на тему бесплатного программного обеспечения и программного обеспечения с открытым кодом. Он является магистром компьютерных наук и философии, и не может решить, какая из сфер для него более интересна. Пока что он любит думать — «Я программирую, следовательно я существую».

Документ
в процессе разработки

Это руководство не завершено. Оно, вероятно, содержит некоторую полезную информацию, но также имеет много пробелов. Прямо сейчас вам также необходимо обратиться к спецификации D-Bus, справочной документации Doxygen и посмотреть несколько примеров того, как другие приложения используют D-Bus.

Определенно, приветствуется улучшение руководства — отправляйте свои исправления или предложения в список рассылки. Если вы создаете привязку D-Bus, пожалуйста, добавьте в этот учебник раздел о вашей привязке, хотя бы небольшой раздел с парой примеров.

Что такое D-Bus?

D-Bus — это система межпроцессного взаимодействия (IPC). Архитектурно он имеет несколько слоев:

• Библиотека libdbus, которая позволяет двум приложениям подключаться друг к другу и обмениваться сообщениями.
• Исполняемый файл демона шины сообщений, построенный на libdbus, к которому могут подключаться несколько приложений. Демон может направлять сообщения от одного приложения к нулю или нескольким другим приложениям.
• Библиотеки враперов или привязок основанных на частичном применении конкретных фреймворков. Например, libdbus-glib и libdbus-qt. Также существуют привязки к таким языкам, как Python. Эти библиотеки-враперы представляют собой API-интерфейс, который следует использовать большинству людей, поскольку это упрощают детали программирования D-Bus. libdbus предназначена для низкоуровневого бэкенда в привязках более высокого уровня. Большая часть API libdbus полезна только для реализации привязок.

Библиотека libdbus поддерживает только соединения точка-точка, подобно raw-сокету. Однако, вместо отправки по соединению потока байтов, вы отправляете сообщения. Сообщения имеют заголовок, определяющий тип сообщения, и тело, содержащее полезные данные. libdbus также абстрагирует конкретно используемый транспорт (сокеты или что-то еще) и обрабатывает такие подробности, как аутентификация.

Демон шины сообщений образует ступицу колеса. Каждая спица колеса представляет собой соединение точка-точка с приложением, использующим libdbus. Приложение отправляет сообщение демону шины по своей спице, а демон шины пересылает сообщение другим подключенным приложениям, если это необходимо. Представляйте демон как маршрутизатор.

На обычном компьютере имеется несколько экземпляров демона шины. Первый экземпляр — это глобальный синглтон машины, то есть системный демон, похожий на sendmail или Apache. Этот экземпляр имеет строгие ограничения безопасности на то, какие сообщения он будет принимать, и используется для общесистемной связи. Остальные экземпляры создаются по одному для каждого сеанса входа пользователя. Эти экземпляры позволяют приложениям в сеансе пользователя взаимодействовать друг с другом.

Общесистемный и индивидуальные демоны разделены. Обычный внутрисессионный IPC не использует шину сообщений общесистемного процесса, и наоборот.

Применения D-Bus

В мире существует очень много технологий, заявленная цель которых — «межпроцессное взаимодействие» или «сеть»: CORBA, DCE, DCOM, DCOP, XML-RPC, SOAP, MBUS, Internet Communications Engine (ICE) и наверное еще сотни. Каждый из них предназначен для определенных типов использования. D-Bus разработан для двух конкретных случаев:

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

Для случая использования в рамках сеанса рабочего стола, рабочие столы GNOME и KDE имеют в прошлом значительный опыт работы с различными решениями IPC, такими как CORBA и DCOP. D-Bus основан на этом опыте и тщательно адаптирован для удовлетворения потребностей, в частности, этих настольных проектов. D-Bus может подходить или не подходить для других приложений; в FAQ есть некоторые сравнения с другими системами IPC.

Проблема, решаемая общесистемным случаем или случаем связи с ОС, хорошо объясняется следующим текстом из проекта Linux Hotplug:

Пробел в текущей поддержке Linux заключается в том, что в настоящее время не поддерживаются политики с каким-либо динамическим компонентом «взаимодействия с пользователем». Например, это часто требуется при первом подключении сетевого адаптера или принтера, а также для определения подходящих мест монтирования дисков. Казалось бы, такие действия могут поддерживаться в любом случае, если можно идентифицировать ответственного человека: однопользовательские рабочие станции или любая система, которая администрируется удаленно.

Это классическая проблема «удаленного системного администратора», когда при горячем подключении должно доставляться событие из его домена безопасности (в данном случае ядра операционной системы) в другой (рабочий стол для вошедшего в систему пользователя или удаленного системного администратора). Любой эффективный ответ должен идти другим путем: удаленный домен предпринимает действия, позволяющие ядру выяснить возможности устройства. (Действие часто может быть выполнено асинхронно, например, позволяя новому оборудованию бездействовать до завершения переговоров.) На момент написания этой статьи в Linux не было широко распространенных решений таких проблем. Однако новые разработки D-Bus могут начать решать эту проблему.

D-Bus может оказаться полезным для целей, отличных от тех, для которых он был разработан. Есть общие свойства, которые отличают его от других вариантов IPC:

• Двоичный протокол, предназначенный для асинхронного использования (в духе протокола X Window System);
• Постоянные и надежные соединения остаются открытыми все время;
• Шина сообщений — это демон, а не «рой» или распределенная архитектура;
• Многие вопросы реализации и деплоя описаны, а не остаются неоднозначными/настраиваемыми/подключаемыми.
• Семантика подобна существующей системе DCOP, что позволяет KDE легко ее адаптировать.

Функции безопасности для поддержки режима общесистемной шины сообщений.

Концепции

Некоторые базовые концепции применимы независимо от того, какую платформу приложения вы используете для написания приложения D-Bus. Однако конкретный код, который вы напишете, будет отличаться для приложений GLib, Qt и Python.

Вот диаграмма, которая может помочь вам наглядно представить следующие концепции.

Нативные объекты
и пути к объектам

Ваш фреймворк, вероятно, определяет, что такое «объект»; обычно это базовый класс. Например: java.lang.Object, GObject, QObject, базовый объект python или что-то еще. Назовем их нативным объектом.

Протокол D-Bus низкого уровня и соответствующий API libdbus не оперирует нативными объектами. Однако он предоставляет концепцию, называемую путем к объекту. Идея пути к объекту заключается в том, что привязки более высокого уровня могут давать имена экземплярам собственных объектов и позволяет удаленным приложениям обращаться к ним.

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

/org/kde/kspread/sheet/3/cells/4/5

Удобочитаемые пути — это хороший тон, но вы можете создать объект с именем

/com/mycompany/c5yo817y0c1y1c5b

, если это имеет смысл для вашего приложения.

Разумно начинать пути к объектам с их пространств имен — с компонентов вашего доменного имени (например,

/org/kde

). Благодаря этому разные модули кода в одном процессе не будут мешать друг другу.

Методы и сигналы

У каждого объекта есть члены. Два вида членов — это методы и сигналы. Методы — это операции, которые могут быть вызваны с объектом, с необязательным вводом (они же аргументы или «входные параметры») и выводом (они же возвращаемые значения или «исходящие параметры»). Сигналы — это широковещательные передачи от объекта всем заинтересованным наблюдателям объекта; сигналы могут содержать полезные данные.

На методы, и сигналы ссылаются по их имени, например «Frobate» или «OnClicked».

Интерфейсы

Каждый объект поддерживает один или несколько интерфейсов. Воспринимайте интерфейс как именованную группу методов и сигналов, как в GLib, Qt или Java. Интерфейсы определяют тип экземпляра объекта.

D-Bus идентифицирует интерфейсы с помощью простой строки с именами, например:

org.freedesktop.Introspectable

Большинство привязок будут отображать эти имена интерфейсов непосредственно на соответствующую конструкцию языка программирования, например, на интерфейсы Java или чистые виртуальные классы C++.

Прокси

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

В псевдокоде программирование без прокси может выглядеть так:

Message message = new Message("/remote/object/path", "MethodName", arg1, arg2); 
Connection connection = getBusConnection(); 
connection.send(message); 
Message reply = connection.waitForReply(message); 
if (reply.isError())  
> else Object returnValue = reply.getReturnValue(); 
>

Программирование с использованием прокси может выглядеть так:

Proxy proxy = new Proxy(getBusConnection(), "/remote/object/path"); 
Object returnValue = proxy.MethodName(arg1, arg2);

Шинные имена

Когда приложение подключается к демону шины, который немедленно присваивает ему имя, называемое уникальным именем подключения. Уникальное имя начинается с символа ‘:’ (двоеточия). Эти имена никогда не используются повторно во время существования шинного демона — то есть вы знаете, что данное имя всегда будет относиться к одному и тому же приложению. Примером уникального имени может быть “:34–907”. Цифры после двоеточия не имеют другого значения, кроме их уникальности.

Когда имя сопоставляется с подключением определенного приложения, считается, что это приложение владеет этим именем.

Приложения могут запрашивать дополнительные общепринятые (well-known) имена. Например, вы можете написать спецификацию для определения имени

com.mycompany.TextEditor

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

/com/mycompany/TextFileManager

org.freedesktop.FileHandler.

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

Вы можете думать об уникальных именах как об IP-адресах, а об общепринятых именах как о доменных именах. Таким образом,

com.mycompany.TextEditor

может отображаться например как

:34-907

mycompany.com

сопоставляется с чем-то вроде

192.168.0.5

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

Шинные имена также могут использоваться для координации «одноэкземплярных» приложений. Если, например, вы хотите быть уверенным, что работает только одно приложение

com.mycompany.TextEditor

, закрывайте приложение текстового редактора, если такое шинное имя уже имеет владельца.

Адреса

Приложения, использующие D-Bus, являются либо серверами, либо клиентами. Сервер прослушивает входящие соединения; клиент подключается к серверу. Как только соединение установлено, образуется симметричный поток сообщений. Различие клиент-сервер имеет значение только при настройке соединения.

Если вы, используете демон шины, ваше приложение будет клиентом демона шины. То есть демон шины прослушивает соединения, а ваше приложение инициирует соединение с демоном шины.

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

unix:path=/tmp/abcdef

указывает, что сервер будет прослушивать сокет домена UNIX с путём

/tmp/abcdef

и клиент будет подключаться к этому сокету. Адрес может также определять TCP/IP сокеты или любой другой транспорт, который будет определен в будущих итерациях спецификации D-Bus.

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

Если вы используете D-Bus без демона шины, вам решать, какое приложение будет сервером, а какое — клиентом, а также указать механизм для согласования адреса сервера. Это нетипичный случай.

Большая
концептуальная картина

Собирая все эти концепции воедино, для вызова конкретного метода для конкретного экземпляра объекта, необходимо назвать несколько вложенных компонентов:

Шинное имя указано в квадратных скобках, чтобы указать, что оно необязательно — вы указываете имя только для маршрутизации вызова метода в нужном приложение при использовании демона шины. Если у вас есть прямое соединение с другим приложением, то демон шины отсутствует и шинные имена не используются.

Адрес -> [Шинное имя] -> Путь -> Интерфейс -> Метод

Интерфейс также не является обязательным, в первую очередь по историческим причинам; DCOP не требует указания интерфейса, вместо этого просто запрещает дублирование имен методов в одном экземпляре объекта. Таким образом, D-Bus позволит вам не указывать интерфейс, но если имя вашего метода неоднозначно, то не определено, какой метод будет вызван.

За кулисами сообщения

D-Bus работает, отправляя сообщения между процессами. Если вы используете привязку достаточно высокого уровня, возможно вам не понадобится работать с сообщениями напрямую.

Есть 4 типа сообщений:

• Сообщения о вызове метода запрашивают вызов метода для объекта;
• Сообщения о завершении метода возвращают результаты вызова метода;
• Сообщения об ошибках возвращают исключение, возникшее при вызове метода;
• Сигнальные сообщения — это уведомления о том, что данный сигнал был послан (что произошло событие). Вы также можете понимать это как «сообщениях о событиях».

Вызов метода очень просто сопоставляется с сообщениями: вы отправляете сообщение о вызове метода и получаете в ответ либо сообщение о завершении метода, либо сообщение об ошибке.

У каждого сообщения есть заголовок, содержащий поля, и тело, включающее аргументы. Вы можете думать о заголовке как о маршрутной информации для сообщения, а о теле — как о полезной нагрузке. Поля заголовка могут включать шинное имя отправителя, шинное имя назначения, имя метода или сигнала и так далее. Одно из полей заголовка — это сигнатура типа, описывающая значения, находящиеся в теле. Например, буква «i» означает «32-битное целое число», поэтому сигнатура «ii» означает, что полезная нагрузка содержит два 32-битных целых числа.

За кулисами вызова метода

Вызов метода в D-Bus состоит из двух сообщений; сообщение о вызове метода, отправленное из процесса A в процесс B, и сообщение ответа соответствующего метода, отправленное из процесса B в процесс A. И вызов, и сообщение ответа маршрутизируются через демон шины. Вызывающий включает в каждое сообщение о вызове другой серийный номер, и ответное сообщение включает этот номер, чтобы вызывающий процесс мог сопоставить ответы с вызовами.

Сообщение о вызове будет содержать любые аргументы метода. Ответное сообщение может указывать на ошибку или может содержать данные, возвращаемые методом.

Вызов метода в D-Bus происходит следующим образом:

• Привязка языка может предоставлять прокси, так что вызов метода внутрипроцессного объекта вызывает метод удаленного объекта в другом процессе. Если это так, приложение вызывает метод на прокси-сервере, и прокси создает сообщение о вызове метода для отправки удаленному процессу.
• Для более низкоуровневых API приложение может создать сообщение о вызове метода само, без использования прокси.
• В любом случае сообщение о вызове метода содержит: имя шины, принадлежащее удаленному процессу, название метода, аргументы метода, путь к объекту внутри удаленного процесса и, опционально, имя интерфейса, определяющего метод.
• Сообщение о вызове метода отправляется демону шины.
• Демон шины просматривает шинное имя назначения. Если это имя принадлежит процессу, демон шины перенаправляет вызов метода этому процессу. В противном случае демон шины создает сообщение об ошибке и отправляет его обратно в качестве ответа на сообщение о вызове метода.
• Принимающий процесс распаковывает сообщение о вызове метода. В простой ситуации низкоуровневого API он может немедленно запустить метод и отправить ответное сообщение метода демону шины. При использовании API привязки высокого уровня, привязка может проверять путь к объекту, интерфейс и имя метода и преобразовывать сообщение вызова метода в вызов метода для нативного объекта (GObject, java.lang.Object, QObject, и т. д.), а затем преобразовать возвращаемое значение из нативного метода в ответное сообщение метода.
• Демон шины получает ответное сообщение метода и отправляет его процессу, который вызвал метод.
• Процесс, вызвавший метод, просматривает ответ метода и использует любые возвращаемые значения, находящиеся в ответе. Ответ также может указывать на то, что произошла ошибка. При использовании привязки ответное сообщение метода может быть преобразовано в возвращаемое значение прокси-метода или в исключение.

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

За кулисами излучения сигнала

Сигнал в D‑Bus состоит из одного сообщения, отправляемого одним процессом любому количеству других процессов. То есть сигнал — это однонаправленная трансляция. Сигнал может содержать аргументы (полезные данные), но поскольку он является широковещательным, он никогда не имеет «возвращаемого значения». Сравните это с вызовом метода (см. #), где сообщение о вызове метода имеет соответствующее ответное сообщение метода.

Эмитент (он же отправитель) сигнала не знает получателей сигнала. Получатели регистрируются с помощью демона шины для получения сигналов на основе «правил соответствия» — эти правила обычно включают отправителя и имя сигнала. Демон шины отправляет каждый сигнал только тем получателям, которые проявили интерес к этому сигналу.

Сигнал в D‑Bus передается следующим образом:

• Сигнальное сообщение создается и отправляется демону шины. При использовании низкоуровневого API это можно сделать вручную, с некоторыми привязками это может быть сделано за вас с помощью привязки, когда нативный объект испускает нативный сигнал или событие.
• Сигнальное сообщение содержит имя интерфейса, определяющего сигнал, название сигнала, шинное имя процесса, отправляющего сигнал; и любые аргументы.
• Любой процесс на шине сообщений может зарегистрировать «правила сопоставления», указывающие, какие сигналы ему интересны. На шине есть список зарегистрированных правил сопоставления.
• Демон шины исследует сигнал и определяет, какие процессы в нем заинтересованы. Он отправляет этим процессам сигнальное сообщение.
• Каждый процесс, получивший сигнал, решает, что с ним делать; при использовании привязки, привязка может излучать нативный сигнал для прокси-объекта. При использовании низкоуровневого API процесс может просто взглянуть на отправителя сигнала и имя и решить, что делать на основании этого.

Интроспекция

Объекты D-Bus могут поддерживать интерфейс

org.freedesktop.DBus.Introspectable

У этого интерфейса есть один метод Introspect, который не принимает аргументов и возвращает строку XML. Строка XML описывает интерфейсы, методы и сигналы объекта. См. Спецификацию D-Bus для получения более подробной информации об этом формате интроспекции.

GLib API

Рекомендуемый GLib API для D-Bus — GDBus, который распространяется с GLib начиная с версии 2.26. Здесь это не задокументировано, для получения подробной информации о том, как использовать GDBus см. Документацию GLib по ссылке:

Также существует более старый API, dbus-glib. Он устарел и не должен использоваться в новом коде. По возможности также рекомендуется переносить существующий код из dbus-glib в GDBus.

Python API

Python API, dbus-python, теперь документирован отдельно в руководстве dbus-python

(также доступен в doc/tutorial.txt и doc/tutorial.html, если он собран с помощью python-documenttils, в исходном дистрибутиве dbus-python).

Qt API

Привязка Qt для libdbus, QtDBus, распространяется с Qt начиная с версии 4.2. Здесь это не задокументировано. Для получения подробной информации о том, как использовать QtDBus см. документацию Qt