I'm playing around with dbus-monitor to try and understand how dbus is working in Ubuntu environment. I have several questions in this regard:
Could you please let me know how to read the following properly? I understand the big idea, but not the details.
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
I get that the first one is a signal whereas the second is a method. Does destination mean there can be a specific receiver/slot for a signal? What's a member? And are the items of the list following the signal the arguments passed in the signal? What are sender and serials?
I noticed something about the relationship between volume-control and notifications. From what I read from the dbus-monitor output
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
It seems that the notification is triggered by its method. I just don't really understand why it works this way. In my view it would make more sense if there was a signal emitted "notification-audio-volume-medium" while the notification would listen for this signal and react accordingly. If the sending / receiving would be public rather than private, wouldn't it allow for more flexibility and efficiency? For instance if there was a public signal for "notification-audio-volume-medium" then several applications could listen for this signal (which would allow for competing notification applications to come to existence) and developers would just have to be concerned with sending signals, while picking up and handling a signal would be the notifying application's business (or any other program that needs those signals).
I'm just new to Dbus and want to learn more as I am working with Dbus on Python, mainly to develop some applets. I've seen the dbus-python tutorial and it teaches how to listen to all signals (by specifying neither interface nor path etc.) But how to track methods when they are called, like dbus-monitor does?
If you have the patience to teach how that works, you're welcome.