Dbus linux что это
Что такое Dbus
Если вы достаточно давно пользуетесь операционной системой Linux, то, наверное, уже не раз слышали о сервисе DBus. Он фигурирует в различных логах программ, инструкциях по настройке системы, а также вы можете видеть сервис DBus-daemon, который непонятно зачем загружается при старте системы.
В этой статье мы попытаемся разобраться, что такое DBus, зачем он нужен, а также как его можно использовать для эффективного управления приложениями в системе.
Что такое Dbus?
По сути, DBus состоит из управляющего демона, API для языков программирования, с помощью которых приложения могут взаимодействовать с системой и консольного клиента.
Каждое приложение, которое хочет работать с DBus, должно зарегистрировать свой сервис в демоне DBus. Поскольку все приложения и сервисы могут беспрепятственно обмениваться сообщениями, этот способ еще называется шина DBus. На шине каждое приложение имеет свой адрес, а каждое сообщение имеет своего отправителя и адресата. Приложение может обмениваться сообщениями даже не с одним, а несколькими приложениями одновременно. Каждое приложение может отправлять сообщения и прослушивать входящие.
Этот механизм дает системе огромную гибкость, например, программы могут подписываться на сообщения о подключении новых устройств, изменении настроек, изменении состояния системы и многое другое. Все это с помощью стандартизированного интерфейса DBus, что гарантирует совместимость. Также программы могут регистрировать свои сервисы таким образом, чтобы программа запускалась только при поступлении сообщений и не работала в фоне.
Объекты Dbus
Каждое приложение, которое использует Dbus, регистрирует свой объект, а также может регистрировать несколько интерфейсов. Когда объекту отправляется сообщение, его получает и приложение. У каждого объекта уникальное имя. Оно похоже на путь в файловой системе. Чтобы имя каждого объекта было уникальным в нем используется префикс разработчика, например, /org/kde или /com/redhat.
Путь объекта DBus состоит из трех частей:
Несколько примеров объектов:
Части имени объектов разделены точкой. Каждый объект имеет один или несколько интерфейсов, которым можно отправлять сообщения.
Интерфейсы имеют очень похожий путь на путь объекта, в некоторых случаях, имя интерфейса совпадает с именем объекта, но если интерфейсов несколько, то они могут отличаться. В отличие от объекта имя интерфейса разделено слэшем. Вот несколько примеров имен интерфейсов, в скобках я привел объекты, в которых есть эти интерфейсы:
Сообщения Dbus
Сообщения Dbus это тоже довольно сложная тема. Они бывают четырех разных типов. Это вызовы методов, результаты вызовов, сигналы и ошибки. Dbus проектировался для использования в первую очередь в программах, поэтому и были реализованы такие сложные структуры. Когда осуществляется вызов метода, программа должна обработать данные и потом в ответном сообщении вернуть результат (результат выполнения) или ошибку.
Доступные объекты Dbus
sudo apt install qttools5-dev-tools
Запустив программу через главное меню вы увидите вот такое главное окно:
В программе, как и положено, есть две шины, сессионная и системная. К каждой из них вы можете получить доступ. С помощью программы даже можно отсылать сообщения вызывая методы и меняя свойства. Но это не совсем правильный способ. Как пользоваться Dbus мы рассмотрим ниже.
Как использовать Dbus?
Обращаться к сервисам Dbus можно с помощью консольной утилиты dbus-send. Рассмотрим ее синтаксис:
Рассмотрим опции утилиты:
Таким образом, когда выполняется запрос, скажем method_call утилита отправляет сообщение указанному нами объекту, затем ждет от него ответа, ответ приходит сообщением method_result, и если было указанно, что ответ нужно вывести на экран, он будет выведен. Все поля нужно заполнять полностью, полный путь объекта, полное имя интерфейса и полное имя метода, включая имя интерфейса.
Вы уже знаете, как и где искать нужные вам интерфейсы, а теперь рассмотрим пару примеров отправки сообщений Dbus.
Получаем список сетевых адаптеров NetworkManager:
Включим музыку в плеере VLC:
Методы могут получать параметры, например, перемотаем наш трек на несколько секунд:
Узнать тип переменной можно тоже с помощью qdbusviewer. Кликните по методу правой кнопкой и выберите Call, в открывшемся диалоговом окне будет предложено ввести значение переменной, а также указан ее тип.
Кроме методов, здесь есть переменные. Понять с чем мы имеем дело, методом или переменной можно тоже с помощью qdbusviewer. Для методов будет написано method, для переменных property. Но посмотреть значение переменной не так просто, для этого используется такая конструкция:
Вместо того чтобы обратиться напрямую к переменной интерфейса, мы используем метод org.freedesktop.DBus.Properties.Get объекта /org/mpris/MediaPlayer2 и передаем ему две строки. Имя интерфейса и имя переменной. Данный пример показывает, как посмотреть текущую громкость VLC.
Установить значение переменной еще сложнее. Для этого используется метод org.freedesktop.DBus.Properties.Set:
Пример изменяет громкость воспроизведения VLC. Этот метод принимает уже три параметра две уже знакомые нам строки и новое значение переменной. Значение переменной имеет тип variant и ему нужно задать нужный тип переменной, в нашем случае нужна double. Посмотреть какой тип переменной нужен вам можно в qdbusviewer, кликните по переменной правой кнопкой мыши и нажмите Set Value. Здесь кроме поля ввода значения вы увидите нужный тип переменной.
Выводы
Теперь вы знаете не только что такое Dbus, но и все необходимые основы, чтобы использование Dbus было для вас достаточно простым в вашей системе и вы могли применять его на полную для управления своими программами. Нашли интересную команду Dbus, которая будет полезна другим пользователям? Напишите в комментариях!
Управление Linux десктопом через D-Bus
Используя D-Bus, вы можете персонализировать и автоматизировать ваш десктоп.
Каждая современная Linux среда рабочего стола использует D-Bus, систему, позволяющую программным приложениям общаться друг с другом. Благодаря D-Bus, ваш десктоп может быть настроен точно так, как вы хотите. В этой статье я привожу примеры некоторых возможностей D-Dus. Будьте готовы к модификации вашего десктопа.
D-Bus регистрирует каждую программу, имеющую сервисы, доступные для других приложений. Таким образом, эти приложения видят, какие сервисы доступны. Также, программы могут становиться доступными для событий системных сервисов (например, определять горячую замену железа).
D-Bus не разрешает прямую коммуникацию между процессами, а работает через шину. Системная шина обеспечивает маршрутизацию сообщений между процессами через себя, таким образом, процессы могут взаимодействовать с несколькими приложениями одновременно. Каждое приложение может посылать сообщения на шину или реагировать на события, получаемые через шину.
Работа с D-Bus
Итак, как же можно использовать D-Bus в своем собственном приложении? Основной API написан на С довольно низкого уровня. Он не задумывался для использования программистами приложений. Различные языки программирования и среды разработки, такие как GLib, Qt, Python, Ruby, Perl и Mono имеют надстроенные над этим API связующие слои. Я не буду углубляться в С или GLib (основаная библиотека в GNOME), но я приведу несколько примеров, написанных на скриптовых языках Python и Ruby, а так же примеры скриптов командной оболочки.
Какие приложения используют D-Bus?
Рисунок 1. QDBusViewer работающий в GNOME
Стоит упомянуть, что qdbusviewer показывает только имена сервисов, зарегистрированных на текущий момент. Например, если Pidgin не запущен, то программа просмотра не будет его отображать. Имейте это ввиду, исследуя D-Bus сервисы, доступные в вашей системе.
Мы получим тот же самый список из методов и интерфейсов, что мы видели в qdbusviewer. Например, строку:
method bool org.freedesktop.PowerManagement.GetOnBattery()
Также qdbus позволяет нам вызывать эти методы напрямую. Например, если мы хотим вызвать метод Suspend, выполняем:
Работаем с D-Bus из командной строки
В оставшейся части статьи мы рассмотрим D-Bus функциональность некоторых популярных приложений, а также напишем скрипты для взаимодействия с этими приложениями и автоматизации ряда задач. Надеюсь, это вдохновит вас на взаимодействие с вашими собственными любимыми приложениями. Я буду использовать разные D-Bus инструменты и скриптовые языки для демонстрации различных способов работы с D-Bus.
Я уже упомянул первый способ работы с D-Bus: использование KDE программ qdbusviewer и qdbus. Если вы не работаете в KDE, то можете использовать программы командной строки dbus-send и dbus-monitor, для отсылки и мониторинга D-Bus сообщений, соответственно. Например, вы можете отправить систему в спящий режим, следующей командой:
С помощью этих двух команд, мы можем создать свой собственный скрипт командной оболочки для скринсейвера. Примечание: во время запуска первой команды вы должны сохранить куки в переменную или в файл, а затем заменить значение куки в команде, что выше.
Если вы отлаживаете D-Bus скрипт или наблюдаете за методами и сигналами других D-Bus приложений, то программа командной строки dbus-monitor очень вам в этом поможет. Просто запустите ее через терминал, и вы увидите всю D-Bus активность. dbus-monitor полезен для просмотра D-Bus активности в реальном времени. Если с вашей системой что-то происходит, например пропадает сеть, то на выходе dbus-monitor вы можете видеть как это сообщение поступает на шину D-Bus. Таким образом вы можете узнать какие сигналы или методы должны использоваться для работы с тем или иным событием.
dbus-monitor так же позволяет вам указать ряд выражений, определяющих за чем вы хотите наблюдать, например:
Пишем скрипт для чтения Liferea ленты
Liferea предоставляет скрипт, который делает точно тоже самое, но еще умеет обрабатывать ошибки.
Без клавиатуры
Если вы хотите выполнить более сложные задания, чем вызов отдельных методов, то вы можете написать скрипт командной оболочки, содержащий dbus-send команды, или используйте язык более высокого уровня, для упрощения задачи. Существуют D-Bus привязки для Python, Ruby и Java языков.
В следующем примере, я реализую скрипт на Python, который меняет ваш статус в Pidgin на “Away from keyboard”, при активизации скринсейвера. Здесь имеются два аспекта D-Bus: скрипт ждет сигнала от скринсейвера, и затем он вызывает метод в Pidgin. Скрипт показан в листинге 1.
Листинг 1. pidgin_screensaver.py
Далее функция проверяет переменную state, которая является аргументом функции pidgin_status_func (я объясню, что означает этот аргумент далее). Если аргумент правдив, то сообщению нового статуса “afk” присваивается значение “Away from keyboard”, и статус активируется. В результате Pidgin показывает ваш статус как “afk», с сообщением “Away from keyboard”.
Pidgin имеет очень обширный D-Bus интерфейс; вы можете делать с помощью него практически все. Пусть этот пример послужит вам вдохновением для создания каких-нибудь креативных задач в Pidgin!
Проигрывание с помощью D-Bus
Давайте посмотрим на другой пример, на этот раз на Ruby. Мы создадим скрипт, который будет показывать текущую песню, играющую в Rhythmbox, вместо вашего статуса в Pidgin (Листинг 2).
Листинг 2. pidgin_rhythmbox.rb
Здесь мы видим команды такого же типа, как и в скрипте на Python: начинаем D-Bus сессию, определяем D-Bus сервис, объекты и интерфейс, и определяем приемник сигнала. Цикл постоянно работает для прослушивания D-Bus сигнала.
Конечно, все это можно немного привести в порядок. Например, на данный момент, в качестве статусного сообщения мы показываем только путь к файлу песни. Я предоставляю вам возможность самим заменить путь к файлу на соответствующий ID3 тег.
Заключение
Приложение
Разбираемся с D-BUS
Прикладные программы, ядро операционной системы и даже ваш мобильный телефон могут информировать вас о наступивших событиях, что позволит вам использовать ваш компьютер с максимальным удобством. В этой статье рассказывается о том, как работает D-BUS и как приложения могут использовать эту систему.
D-BUS представляет собой систему межпроцессного взаимодействия (IPC), предоставляющую простой и мощный механизм, с помощью которого приложения могут обмениваться друг с другом информацией и инициировать запросы служб. Система D-BUS была спроектирована с нуля в условиях необходимости удовлетворения запросов современных Linux-систем. Главной задачей D-BUS является замена таких систем удаленных вызовов объектов, как CORBA и DCOP, используемых в GNOME и KDE соответственно. В идеальном случае, система D-BUS может стать унифицированной и гибкой системой межпроцессного взаимодействия для обоих вышеупомянутых окружений рабочего стола, удовлетворяющей их нуждам и используемой для реализации новых возможностей.
Почему система D-BUS уникальна
Система D-BUS отлична от других систем межпроцессного взаимодействия по ряду причин. Во-первых, основной единицей межпроцессного взаимодействия в D-BUS является сообщение, а не поток данных. Таким образом, D-BUS разделяет данные взаимодействующих приложений на отдельные сообщения, состоящие из заголовков (метаданных) и полезной нагрузки (данных). Сообщений находятся в бинарном, типизированном, полностью выровненном и простом формате. Эта часть протокола унаследована из сетевых протоколов обмена данными. Этот подход резко отличается от подхода, используемого в других системах межпроцессного взаимодействия, где в подавляющем большинстве используются различные байтовые потоки, а не отдельные сообщения.
Во-вторых, в основе D-BUS лежит понятие шины. Простейшей формой взаимодействия процессов является передача данных от процесса к процессу. Тем не менее, D-BUS предоставляет системную службу, известную как служба системной шины сообщений, которая перенаправляет сообщения между процессами, работающими с конкретной шиной. Таким образом реализуется топология шины, позволяющая процессам передавать сообщения одному или нескольким приложениям одновременно. Приложения могут отправлять или ожидать приема различных событий на шине.
Последней уникальной возможностью является создание не одной, а сразу двух таких шин: шины системы и шины сессии. Шина системы является глобальной шиной, работающей на уровне системы. Все пользователи системы, имеющие соответствующие права, могут использовать эту шину, что вводит концепцию общесистемных событий. Шина сессии создается во время входа пользователя в систему и работает на уровне пользователя или сессии. Эта шина используется исключительно определенным пользователем в рамках определенной сессии как система межпроцессного взаимодействия и удаленного вызова объектов для пользовательских приложений.
Концепции D-BUS
Сообщения отправляются объектам. Адресация объектов производится при помощи путей, таких как /org/cups/printers/queue. Процессы, работающие с шинами, ассоциируются с объектами и реализуют интерфейсы этих объектов.
D-BUS поддерживает множество типов сообщений, таких как: сигналы, вызовы методов, возврат результатов вызовов методов и сообщения об ошибках. Под сигналами понимаются уведомления о наступлении определенных событий. Они являются простыми, асинхронными односторонними сообщениями. Сообщения с вызовами методов позволяют приложению отправить запрос на вызов метода удаленного объекта. Сообщения, возвращающие результат вызова методов, предоставляют значение, которое было возвращено в результате вызова метода. Сообщения об ошибках позволяют обрабатывать исключения в результате вызова методов.
В системе D-BUS используется полная типизация и возможно безопасное использование типов. И заголовок сообщения и полезные данные полностью типизированы. Поддерживаемые типы данных: байты (byte), булевые значения (Boolean), 32-битные целочисленные значения (32-bit integer), 32-битные беззнаковые целочисленные значения (32-bit unsigned integer), 64-битные целочисленные значения (64-bit integer), 64-битные беззнаковые целочисленные значения (64-bit unsigned integer), числа с плавающей точкой двойной точности (double-precision floating point) и строки(string). Специальный тип массива (array) позволяет группировать эти значения. Тип словаря (DICT) позволяет создавать пары ключ/значение.
Система D-BUS безопасна. Она реализует простой протокол, основанный на профилях SASL для аутентификации соединений приложений один-на-один. На уровне шин чтение и запись сообщений со стороны определенного интерфейса контролируется системой безопасности. Администратор может контролировать доступ любого интерфейса к шине. Служба D-BUS изначально проектировалась с учетом системы безопасности.
Почему следует использовать D-BUS
Все вышесказанное здорово звучит, но в чем же преимущества? Во-первых, концепция системной шины является нововведением. Одна шина, доступная всем компонентам системы, позволяет распространять сообщения начиная от событий ядра (смотрите раздел «Уровень событий ядра») и заканчивая высокоуровневыми приложениями в рамках системы. Linux со своими хорошо спроектированными интерфейсами и четко разделенными уровнями систем, не имел хорошей системы интеграции. Шина системы D-BUS улучшает интеграцию системных компонентов без нарушения хорошо зарекомендовавших себя правил разработки. Теперь такие события, как заполнение жесткого диска или опустошение очереди печати или даже разрядка батареи ноутбука могут сопровождаться всплывающей подсказкой в системном трее и событием, доступным заинтересованным в нем приложениям, позволяющим системе ответить и отреагировать на него соответствующим образом. Сигналы отправляются асинхронно без необходимости постоянной проверки доступности новых событий.
Уровень событий ядра
Под уровнем событий ядра понимается механизм обмена сообщениями между пространствами ядра и пользователя, реализуемый при помощи высокоскоростного netlink-сокета. Этот механизм связан с системой D-BUS и позволяет ядру генерировать сигналы D-BUS!
Уровень событий ядра связан с файловой системой sysfs, являющейся отображением внутренних объектов ядра (kobjects) и расположенной в /sysfs в современных дистрибутивах Linux. Каждая директория sysfs связана с объектом ядра (kobject), являющимся структурой ядра, предназначенной для внутреннего представления объектов; sysfs является иерархией объектов, экспортируемой из ядра в виде файловой системы.
Каждое событие уровня событий ядра моделируется таким образом, что в качестве инициатора приводится путь в файловой системе sysfs. Таким образом, события выглядят как инициированные объектами ядра. Пути из файловой системы sysfs легко приводятся к путям объектов D-BUS, связывая уровень событий ядра и систему D-BUS естественным образом. Уровень событий ядра был впервые представлен в ядре версии 2.6.10-rc1.
Во-вторых, шина сессий предоставляет механизмы межпроцессного взаимодействия и удаленного вызова процедур, предоставляя в перспективе унифицированную систему для GNOME и KDE. Целью D-BUS является создание системы с функциями CORBA, лучшей чем CORBA и системы с функциями DCOP, лучшей чем DCOP, удовлетворяя требованиям обоих проектов и в то же время, предоставляя дополнительные возможности.
К тому же, D-BUS обладает этими возможностями, оставаясь простой и эффективной системой.
Добавление поддержки D-BUS в ваши приложения
Основа системы D-BUS разработана на языке программирования C и ее API является обширным и довольно низкоуровневым. Существуют высокоуровневые API, используемые поверх этого API для различных языков программирования и компонентов, включая Glib, Python, Qt и Mono. Наряду с предоставлением API для различных языков программирования, высокоуровневые API предоставляют и поддержку функций, специфических для отдельных системных компонентов. Например, API для Glib представляют соединения D-BUS как объекты GObject и позволяют отправку сообщений для интеграции в цикл приема событий (Glib mainloop). Предпочтительным методом использования D-BUS в программе является использование высокоуровневых API для выбранного языка программирования и программного компонента для достижения удобства использования и повышения функциональности.
Давайте рассмотрим простейшие примеры использования D-BUS в ваших приложениях. Сначала рассмотрим API для языка C, затем перейдем к рассмотрению кода с использованием интерфейса Glib.
Использование API D-BUS для языка C
Этот код отправляет сигнал «Feathers» с адреса org.pirate.parrot.attr с полезной нагрузкой в виде двух полей, каждое из которых является строкой: «Shiny» и «Well Groomed». Любое приложение, работающее с системной шиной сообщений, с достаточными правами может выбрать эту службу и принять сигнал.
Интерфейс Glib
В этом примере мы присоединились к шине пользователя. Этот вызов связывает соединение с циклом событий Glib, позволяя совершать операции ввода/вывода вместе с работой с сообщениями D-BUS.
Функция Peel принимает дин параметр в виде целого числа. Если метод возвратит значение, отличное от нуля, он корректно завершился и в переменной ret содержится значение, возвращенное этой функцией. Типы данных, которые принимает определенный метод, описываются при реализации метода. Например, мы не передавали тип DBUS_TYPE_STRING вместо типа DBUS_TYPE_INT32.
Главным преимуществом использования высокоуровневых API является интеграция в цикл приема событий, позволяющая разработчикам обрабатывать различные сообщения D-BUS вместе с операциями ввода-вывода и событиями пользовательского интерфейса. Заголовочный файл описывает ряд функций для интеграции D-BUS в цикл приема событий Glib.
Заключение
D-BUS является мощной и простой системой межпроцессного взаимодействия, которая с успехом улучшит интеграцию и расширит функциональность Linux-систем. Пользователи рано или поздно столкнутся со все большим количеством приложений, использующих D-BUS. Имея на руках эту статью, есть все основания рассматривать D-BUS не как ужасную зависимость, а как блестящую особенность системы. На интернет-ресурсах можно найти ряд примеров программ, использующих D-BUS. Разработчики со временем будут вынуждены добавлять поддержку D-BUS в свои приложения. Также существует ряд сайтов с описанием возможностей и примерами использования D-BUS. Конечно же, лучшим справочным материалом является исходный код, и, к счастью, его сейчас очень много.
Хозяин цифровой магистрали: Тотальный контроль приложений с системой D-Bus
Содержание статьи
Используя межпрограммный интерфейс D-Bus, можно управлять поведением любого современного графического Linux-приложения извне — из своих скриптов или повесив нужное действие на сочетание клавиш. В этой статье мы рассмотрим несколько полезных трюков с D-Bus, которые пригодятся любому пользователю.
Вкратце о D-BUS
Чтобы ты понимал, о чем идет речь, нужно разобраться, как работает D-Bus, и что это вообще такое. Сразу предупреждаю, сейчас будет немного скучно. Но без теории никак. Иначе вместо того, чтобы практически использовать D-Bus, ты ограничишься только трюками из этой статьи.
D-Bus — это система межпроцессного взаимодействия, которая обеспечивает тесную связь десктопных приложений между собой, и связь между десктопными приложениями и системными сервисами. Например, через D-Bus программы могут узнать о наличии/ отсутствии сети у Network Manager’а; твой музыкальный плеер переключится на следующий трек и сообщит IM-клиенту название композиции, причем твои собеседники увидят ее у тебя в статусе; рабочий стол сменит фоновую картинку; все окна с рабочих столов выстроятся в режиме scale; автоматически подмонтируется вставленное USB-устройство (даже если нет прав рута, связка HAL + D-Bus + pmount) и т.д.
Что интересно, D-Bus не зависит от конкретной среды (KDE, GNOME, Xfce…), но при этом прекрасно интегрируется в каждую из них. В основе структуры D-Bus лежит понятие шины. Это специальный механизм, с помощью которого процессы обмениваются данными.
Первая и самая главная — системная шина, создается при запуске демона D-Bus, используется для «общения» различных демонов и практически недоступна для пользовательских приложений. Сессионная шина, наоборот, создается для пользователя, вошедшего в систему — по ней будут «общаться» приложения, с которыми работает пользователь. Для каждой сессионной шины запускается отдельная копия демона.
У каждого сообщения, передаваемого по шине, есть отправитель и получатель. Адреса отправителя и получателя называются путями объектов, то есть D-Bus предполагает, что каждое приложение состоит из набора объектов, а сообщения пересылаются не между приложениями, а между объектами приложений. У каждого объекта может быть один или более интерфейсов. Интерфейсы представлены в виде именованных групп методов и сигналов, как в интерфейсах Glib, Qt и Java.
D-Bus предусматривает собственную концепцию сервисов. Сервис — это уникальное местоположение приложения на шине. При запуске программа регистрирует один или несколько сервисов на шине, которыми она будет владеть, пока не освободит их. До момента освобождения ни одно другое приложение не сможет занять уже занятый сервис.
Сервисы именуются аналогично интерфейсам. С помощью сервисов можно реализовать автоматический запуск необходимых приложений при поступлении сообщений. Для этого нужно включить автоактивацию и в настройках D-Bus сопоставить с сервисом определенное приложение, тогда D-Bus запустит приложение при поступлении сообщения на тот или иной сервис. При завершении программы освобождаются все зарегистрированные при ее запуске сервисы.
В D-Bus у каждого объекта свое уникальное имя. Имя объекта напоминает путь в файловой системе, например, org/kde/ kspread/sheets/1/cells/1/1. Обычно путь имеет какую-нибудь смысловую нагрузку. Например, в данном случае мы обращаемся к ячейке 1:1 на первом листе электронной книги KSpread. Но имена могут быть совершенно бессмысленными, например, /com/appl1/c5444sf956a. Тут все зависит от фантазии разработчиков.
На этом скучная часть статьи закончилась, и можно приступать к практике.
D-BUS и скринсейверы
Начнем с самых простых трюков, связанных с D-Bus и скринсейверами. Заблокировать экран можно следующей командой:
$ qdbus org.kde.krunner /ScreenSaver Lock
Иногда напрягает, что хранитель экрана вообще запускается. Ну не нужен он мне. Конечно, в настройках KDE его можно отключить, но раз сегодня мы говорим о D-Bus, то тебе пригодится следующая команда:
$ qdbus org.kde.krunner /ScreenSaver \
SimulateUserActivity
Кстати, в некоторых случаях X-сервер может потушить экран. Чтобы обойти эту «фичу», нужно ввести команду:
Первый 0 — это время в секундах до гашения монитора без его выключения, второй 0 — это время до перехода в режим ожидания, а третий — время до выключения монитора.
Вообще, вместо команды xset можно править xorg.conf, но учитывая, что в современных дистрибутивах он отсутствует, лучше все-таки использовать команду xset.
Вернемся к методу SimulateUserActivity. Метод, как следует из его названия, имитирует активность пользователя. Его нужно вызывать периодически. Но не будешь же ты вводить приведенную выше команду, скажем, каждые 30 секунд? Тогда можно набросать небольшой сценарий:
Сценарию нужно передать командную строку. Да, именно командную строку, тогда скрипт запустит приложение и будет имитировать активность пользователя. Сохрани сценарий как /usr/bin/simulate. После этого установи права доступа и запускай:
$ sudo chmod +x /usr/bin/simulate
$ simulate mplayer film.avi
Действительно, у MPlayer есть параметр ‘-stopxscreensaver’, но у других проигрывателей подобного параметра может и не оказаться.
Трюки с буфером обмена
В Windows я использовал довольно неплохой менеджер закачек — FlashGet. Он активировался, как только в буфере обмена появлялась ссылка. Всплывало окно, где нужно было либо подтвердить закачку, либо отказаться от нее. Сейчас мы попробуем реализовать подобный мониторинг буфера обмена в Linux с помощью D-Bus. Следующая команда выводит содержимое клипборда:
$ qdbus org.kde.klipper /klipper \
getClipboardContents
Теперь напишем простенький сценарий, выводящий содержимое буфера обмена, если в нем есть URL (для простоты мы будем учитывать только http://):
Мы сохраняем содержимое буфера обмена в переменной in, а затем передаем ее программе wget, которая и загружает файл. Конечно, наш «менеджер загрузок» далек от совершенства. Вопервых, нужно научить его реагировать и на FTP-адреса. Во-вторых, если в буфере обмена кроме URL будет еще и произвольный текст, например, «Ссылка http://server/file», то сценарий завершится с ошибкой. Тут можно так и оставить (FlashGet тоже не активируется, если в буфере обмена есть еще что-то, кроме URL), а можно посредством регулярных выражений выделить URL, и получить его с помощью wget. В любом случае, все это уже не относится к D-Bus и буферу обмена, поэтому пусть это будет твоим домашним заданием. Кроме метода getClipboardContents есть метод setClipboardContents, устанавливающий содержимое буфера обмена. Использовать его можно так:
Управляем проигрывателем AMAROK 2 с помощью D-BUS
Следующие команды аналогичны нажатию кнопок Play, Pause, Next, Prev, Stop, Quit:
Кстати, у Amarok2 есть поддержка Last.FM, но для этого сервиса поддерж иваются только методы Stop и Play. Приведу воркэраунд для пропуска текущей песни:
Вывести всю информацию о текущем треке можно следующим образом:
$ qdbus org.kde.amarok /Player GetMetadata
Еще очень полезный метод GetStatus, возвращающий 4 целых числа:
Управление проигрывателями VLC и XMMS
Аналогично можно управлять и другим проигрывателем — VLC. Вот действие, аналогичное нажатию на кнопку воспроизведения:
Как только я начал свое знакомство с Linux, лучшим медиа-проигрывателем для него был XMMS. Отчасти его популярность заключалась во внешней схожести с популярным в то время Winamp. Недавно наткнулся на полное описание D-Bus интерфейса современной версии XMMS (XMMS 2): http://xmms2.org/wiki/MPRIS#D-Bus. Если тебе нравится XMMS 2, то эта ссылка будет весьма полезной для тебя.
Интерфейс org.freedesktop.mediaplayer (MPRIS 1.0 DBUS API)
Все популярные проигрыватели, такие как Amarok, VLC, XMMS, Audacious, BMPx, используют интерфейс MPRIS. Следовательно, можно написать универсальный сценарий управления проигрывателями, в качестве параметра которому передавать название плеера. Берем команду dbus-send и вместо значения параметра ‘—dest’ указываем своего фаворита:
Далее все стандартно. Управление проигрывателем осуществляется через интерфейс org.freedesktop.MediaPlayer объекта /Player. А управление списком композиций — через объект /TrackList.
Регулировка громкости
Установить уровень громкости можно с помощью метода VolumeSet:
Значение может быть в диапазоне 0…100. 0 — звук выключен, 100 — максимальная громкость. Например:
$ qdbus org.kde.amarok /Player VolumeSet 90
Узнать текущее значение громкости можно методом VolumeGet.
А что дальше? Или метод научного тыка
С помощью D-Bus можно управлять практически любым современным графическим Linux-приложением. Поскольку я не могу читать твои мысли, то не могу предусмотреть все трюки, которые ты хотел бы видеть в этой статье. Поэтому я только расскажу, что нужно для самостоятельного исследования объектов и методов D-Bus. Запусти yakuake (это мой любимый терминал в KDE, запускается при нажатии ) и введи команду:
$ qdbus org.kde.yakuake
/KDebug
/Konsole
/MainApplication
/Sessions
/Sessions/1
/yakuake
/yakuake/MainWindow_1
/yakuake/sessions
/yakuake/tabs
/yakuake/window
В результате ты получишь список объектов сервиса org.kde.yakuake. Если ты знаешь, что такое ООП, то уже догадался, что у каждого объекта есть методы. Просмотреть список методов можно так:
qdbus сервис объект
$ qdbus org.kde.yakuake /yakuake/tabs
Приведенная выше команда выводит методы объекта /yakuake/tabs. Например, метод setTabTitle() позволяет установить заголовок вкладки. Для этого методу нужно передать номер сессии и строку — будущий заголовок. Чтобы узнать номер сессии, посмотрим на список методов объекта /yakuake/sessions:
$ qdbus org.kde.yakuake /yakuake/sessions
Номер (идентификатор) активной сессии возвращается методом activeSessionId(). Чтобы получить номер текущей сессии (под сессией в yakuake подразумевается вкладка), нужно ввести команду:
$ qdbus org.kde.yakuake /yakuake/sessions \
activeSessionId
qdbus сервис объект метод
Напишем сценарий, изменяющий заголовок текущей вкладки:
Этот скрипт можно и усовершенствовать. Например, сделать так, чтобы он принимал текст из командной строки (в качестве первого параметра) и подставлял его в заголовок текущей вкладки:
Заключение
Кому не нравится изучать объекты и методы D-Bus в терминале, могут использовать утилиту qdbusviewer из пакета qt4-dev-tools, которая предоставляет более удобный интерфейс для просмотра списков объектов и методов D-Bus. Точное описание объектов и методов ты найдешь на страничке разработчиков той или иной программы. А вот что касается самой D-Bus, то настоятельно рекомендую ознакомиться вот с этим руководством — http://dbus.freedesktop.org/doc/dbus-tutorial.html. Удачи!
Кобра, мыло и все остальные
Приложения в рамках одной среды рабочего стола должны тесно взаимодействовать между собой. В KDE не так давно для этого использовалась система DCOP (Desktop COmmunication Protocol), которая в настоящее время заменена на D-Bus. Кроме DCOP существовала возможность коммуникации с помощью CORBA, SOAP или XML-RPC. Но CORBA требует много системных ресурсов, а SOAP и XML-RPC предназначены больше для веб-сервисов.
Работа с программой мгновенного обмена сообщениями Kopete
Получить массив, содержащий список контактов запущенного Kopete:
Завершение сеанса
Пользовательские сессии и D-Bus
Сохранить текущую сессию можно вот такой командой:
Если ты хочешь сохранить сессию и выйти, набирай: