GNOME Bugzilla – Bug 653256
Use PropertiesChanged in org.freedesktop.DBus.Properties instead of custom one
Last modified: 2014-01-02 21:19:35 UTC
org.freedesktop.NetworkManager is duplicating PropertiesChanged; which now exists in freedesktop.DBus.Properties. This makes stuff like gdbus-codegen generated proxies not to be able to follow properties changes here. I suspect that there are other objects in NM dbus interface that do this. It would be great if this could be fixed for a new version of the interface.
Hi Claudio, I've been thinking about sensible D-Bus APIs for long time and i reached the very same conclusion. D-Bus services should always avoid multiple same-name methods on an object (only differing in interface). D-Bus is said to map well into object-oriented languages but this is only for D-Bus APIs that follow certain recommendations. I'm going to start a document about it: https://fedoraproject.org/wiki/User:Pavlix/D-Bus
So I started to do this long, long ago. There's one big problem though: dbus-glib doesn't allow multiple signals with different signatures on different GInterfaces. NetworkManager already has interface-specific signals named PropertiesChanged, like org.freedesktop.NetworkManager.Device.PropertyChanged. To implement the DBus PC signals, we'd need to define an org.freedesktop.DBus interface with a signal also named PropertiesChanged. That means two signals on the same GObject named PropertiesChanged, with different arguments, and that's just not supported. What we'd need to do is something like "shadow signals" or signal aliases in dbus-glib, which I did a couple years back for properties, see dbus_g_object_type_register_shadow_property(). Basically, just name the signal something different and tell dbus-glib to emit the signal as "PropertiesChanged". This requires patches to dbus-glib though, if somebody wants to do patches for that, great. My suggestion though would be to just do this when we convert NM internally to GDBus.
(In reply to comment #2) > So I started to do this long, long ago. There's one big problem though: > dbus-glib doesn't allow multiple signals with different signatures on different > GInterfaces. To clarify, *on the same object*. So the same object cannot implement both Interface1 with signal "Foo(s)" and Interface2 with signal "Foo(b)", for example.
This is basically CANTFIX for the current API. And when we port to GDBus it will be fixed automatically. *** This bug has been marked as a duplicate of bug 622927 ***