DBus – How to Get a Proxy for a Non-Well-Known DBus Object

application-developmentdbuslibdbusmenupython

I'm endeavouring to use dbus to react to a particular signal (user clicks on an appindicator menu on the unity top panel). From using dbus-monitor, I've found the relevant signal that I'd like to react to:

sender=:1.96 -> dest=:1.232 serial=2091 path=/org/ayatana/NotificationItem/myapp/Menu; interface=com.canonical.dbusmenu; member=AboutToShowGroup
array [
   int32 9
]

Then my plan was to do the following with python:

dbus_proxy = bus.get_object ("BUS.NAME", "PATH")
interface = dbus.Interface (proxy, "INTERFACE")
interface.connect_to_signal ("SIGNAL", my_function)

def my_function:
    # react

In order to understand dbus, I've been using the following two articles:
the dbus-python tutorial and
How to read dbus-monitor output?

However, I'm a bit confused as to what values I should be using for bus name, path, interface and signal in my code. I've tried poking around in qdbus in order to work out the correct values, but I can't seem to find what I'm looking for. I think I've been thrown off because get_object requires a "well-known" name, but all I've got is the numerical unique identifiers for sender, dest.

Any nudge in the right direction would be greatly appreciated.

Best Answer

The add_signal_receiver function can be used without specifying a bus name. This can be useful for capturing signals when the bus name, interface or specific signal name is unknown.

session_bus = dbus.SessionBus()

session_bus.add_signal_receiver(self.do_something,
                                signal_name=None,
                                dbus_interface=None,
                                bus_name=None, 
                                path=None)

The above code calls the do_something method every time a signal is received on the session bus.

In my original question, I stated I wanted to respond to 'AboutToShowGroup'. However, after closer inspection of the 'com.canonical.dbusmenu' interface, I realised it is in fact a method and not a signal. I have since chosen another signal to react to.

D-Bus introduction

D-Bus provides means for communicating between services. Services can be anonymous (identified solely by bus address, like :1.6), and services can aquire well-known names, like org.freedesktop.Notifications or org.freedesktop.NetworkManager. The sender and destination which you can see in the logs are services. "Null destination" means broadcast: delivery to all services.
A service can export one or several objects to the bus. Objects are given object paths, like /org/freedesktop/NetworkManager/ActiveConnection/1 or /org/ayatana/menu/DA00003. Object paths use slash as separator, like filesystem paths.
Each object can support one or several interfaces. An interface is nothing more than a set of methods and signals, coloquially known as members (very similar to OOP interface). Methods and signals have fixed signatures. Members are always namespaced within well-known interface names.
Once published, well-known names never change.
Any service can connect to another service's signals and asynchronously call its methods. Any service can emit signals.

Signals

Now to your specific questions.

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

Yes, you're right, this is a signal. It's broadcasted by service :1.1948, and "self" object is /org/ayatana/menu/DA00003. The signal has name ItemPropertyUpdated which is defined in the interface org.ayatana.dbusmenu (like org.ayatana.dbusmenu::ItemPropertyUpdated in C++). The serial, I guess, is a kind of unique identifier of the event on the bus.

Then we see the signal arguments. According to the interface documentation, the first int32 argument is an item's id, second string is its property name, and the third variant is the property value. So, the /org/ayatana/menu/DA00003 object is notifying us that the item id #23 changed its enabled property to true.

Another example on signals:

signal sender=:1.1602 -> dest=(null destination) serial=20408 path=/im/pidgin/purple/PurpleObject; interface=im.pidgin.purple.PurpleInterface; member=SendingChatMsg
   int32 47893
   string "test"
   uint32 1
signal sender=:1.1602 -> dest=(null destination) serial=20409 path=/im/pidgin/purple/PurpleObject; interface=im.pidgin.purple.PurpleInterface; member=IrcSendingText
   int32 64170
   string "PRIVMSG #chat :test

I sent a text message "test" using Pidgin to an IRC channel, and /im/pidgin/purple/PurpleObject emitted two signals under the im.pidgin.purple.PurpleInterface interface: first a general SendingChatMsg, then a more specific IrcSendingText.

Methods

Now methods. Methods are a way to ask D-Bus objects to do something, or to perform some query and return data. They are quite similar to classic OOP methods, except that D-Bus methods are called asynchronously.

Let's call a D-Bus method programmatically.

import dbus, dbus.proxies

#-- connect to the session bus (as opposed to the system bus)
session = dbus.SessionBus()

#-- create proxy object of D-Bus object
obj_proxy = dbus.proxies.ProxyObject(conn=session,
         bus_name="org.freedesktop.Notifications",     #-- name of the service we are retrieving object from
         object_path="/org/freedesktop/Notifications") #-- the object path

#-- create proxy object of the D-Bus object wrapped into specific interface
intf_proxy = dbus.proxies.Interface(obj_proxy, "org.freedesktop.Notifications")

#-- lastly, create proxy object of the D-Bus method
method_proxy = intf_proxy.get_dbus_method("Notify")

#-- ... and call the method
method_proxy("test from python",
             dbus.UInt32(0),
             "bluetooth",     #-- icon name
             "Notification summary",
             "Here goes notification body",
             [], {},
             5) #-- timeout

Note the arguments, especially the icon name. In your example "notification-audio-volume-medium" was the icon of medium-powered volume speaker.

Custom services

It is absolutely possible to run your own D-Bus services, export your own D-Bus objects and define your own D-Bus interfaces with your own methods and signals. This all can be done in Python pretty easily once you grasp the overall concept and read the dbus module documentation. :)

dbus – How to Get List of All Available DBus Properties

Have you tried using the d-feet tool?

sudo apt-get install d-feet

enter image description here

Try that and see if you make progress.

Best Answer

Related Solutions

Read dbus-monitor Output – How to Guide

D-Bus introduction

Signals

Methods

Custom services

dbus – How to Get List of All Available DBus Properties

Related Question