Как читать выход dbus-монитора?

Question 1

Я играю с dbus-монитором, чтобы попытаться понять, как dbus работает в среде Ubuntu. У меня есть несколько вопросов в этом отношении:

Не могли бы вы дать мне знать, как правильно читать следующее? Я понимаю большую идею, но не подробности.

signal sender=:1.1948 -> dest=(null destination) serial=1829990 path=/org/ayatana/menu/DA00003; interface=org.ayatana.dbusmenu; member=ItemPropertyUpdated
int32 23
string "enabled"
variant boolean true
method call sender=:1.6 -> dest=org.freedesktop.Notifications serial=1399 path=/org/freedesktop/Notifications; interface=org.freedesktop.Notifications;
member=GetCapabilities

Я понимаю, что первый - это сигнал, а второй - метод. Имеет ли назначение означает, что может быть конкретный приемник / слот для сигнала? Что такое член? И являются ли элементы списка, следующие за сигналом, аргументами, переданными в сигнале? Что такое отправитель и сериалы? Я заметил что-то об отношениях между контролем громкости и уведомлениями. Из того, что я прочитал с выхода dbus-монитора

method call sender=:1.6 -> dest=org.freedesktop.Notifications serial=1400 path=/org/freedesktop/Notifications; interface=org.freedesktop.Notifications; member=Notify
string "gnome-settings-daemon"
uint32 0
string "notification-audio-volume-medium"
string " "
string ""
array [
]
array [
dict entry(
string "value"
variant int32 38
)
dict entry(
string "x-canonical-private-synchronous"
variant string "volume"
)
]
int32 -1

Кажется, что уведомление вызвано его методом. Я просто не понимаю, почему это работает. На мой взгляд, было бы более разумно, если бы был сигнал, излучаемый «уведомлением-аудио-объемным носителем», в то время как уведомление прослушивало этот сигнал и реагировало соответствующим образом. Если отправка / получение будет публичной, а не частной, не позволит ли она обеспечить большую гибкость и эффективность? Например, если был общедоступный сигнал для «notification-audio-volume-medium», тогда несколько приложений могли бы прослушивать этот сигнал (что позволило бы создавать конкурирующие приложения для уведомлений), а разработчикам просто нужно было бы отправлять сигналы , в то время как сбор и обработка сигнала - это бизнес уведомляющего приложения (или любая другая программа, которая нуждается в этих сигналах). Я просто знаком с Dbus и хочу узнать больше, поскольку я работаю с Dbus на Python, в основном для разработки некоторых апплетов. Я видел учебник dbus-python, и он учит, как слушать все сигналы (не указывая ни интерфейс, ни путь и т. Д.). Но как отслеживать методы, когда они вызываются, например, dbus-monitor?

Если у вас есть терпение, чтобы научить тому, как это работает, пожалуйста.

Question 2

Я также искал решение для сбора уведомлений на рабочем столе через dbus с помощью скрипта python. Этот вопрос был самым близким, с которым я столкнулся с поисковой системой, но написать замену для уведомления-osd показалось излишним:)

Глядя на недавние источники уведомлений, я получил несколько советов о том, как отслеживать сообщения dbus и вот реализация python, с которой я столкнулся:

import gtk
import dbus
from dbus.mainloop.glib import DBusGMainLoop

def filter_cb(bus, message):
    # the NameAcquired message comes through before match string gets applied
    if message.get_member() != "Notify":
        return
    args = message.get_args_list()
    # args are
    # (app_name, notification_id, icon, summary, body, actions, hints, timeout)
    print("Notification from app '%s'" % args[0])
    print("Summary: %s" % args[3])
    print("Body: %s", args[4])


DBusGMainLoop(set_as_default=True)
bus = dbus.SessionBus()
bus.add_match_string(
    "type='method_call',interface='org.freedesktop.Notifications',member='Notify'")
bus.add_message_filter(filter_cb)
gtk.main()

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

Keto · Answer 1 · 25 May 2018 в 21:44

Я также искал решение для сбора уведомлений на рабочем столе через dbus с помощью скрипта python. Этот вопрос был самым близким, с которым я столкнулся с поисковой системой, но написать замену для уведомления-osd показалось излишним:)

Глядя на недавние источники уведомлений, я получил несколько советов о том, как отслеживать сообщения dbus и вот реализация python, с которой я столкнулся:

import gtk
import dbus
from dbus.mainloop.glib import DBusGMainLoop

def filter_cb(bus, message):
    # the NameAcquired message comes through before match string gets applied
    if message.get_member() != "Notify":
        return
    args = message.get_args_list()
    # args are
    # (app_name, notification_id, icon, summary, body, actions, hints, timeout)
    print("Notification from app '%s'" % args[0])
    print("Summary: %s" % args[3])
    print("Body: %s", args[4])


DBusGMainLoop(set_as_default=True)
bus = dbus.SessionBus()
bus.add_match_string(
    "type='method_call',interface='org.freedesktop.Notifications',member='Notify'")
bus.add_message_filter(filter_cb)
gtk.main()

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

Это помогло мне! Большое спасибо! Несколько предложений для вас: " type = 'method_call' " не является обязательным, так как уведомления используют только вызовы метода . Никаких сигналов в спецификации. Кроме того, "member =" Notify "" также не требуется, поскольку вы уже фильтруете это в своей функции (и, как вы правильно сказали, вы не можете избежать этого из-за первого сообщения NameAquired), — MestreLion, 20 September 2012 в 05:50

Как читать выход dbus-монитора?

1 ответ

Другие вопросы по тегам:

Похожие вопросы: