PropertiesChanged signal, take 2

[David Zeuthen]

Hey,

On Wed, May 12, 2010 at 2:58 PM, Thiago Macieira <thiago at kde.org> wrote:
> How do you detect whether the signal is implemented? You have to parse the
> remote object's introspection?

Yup, that's one option. The spec wording is that if you include the
signal in the introspection XML, then you promise to emit it (except
for properties you opt out with using the annotation).

In general, I think it's the same as for other parts of a D-Bus
interface - the documentation for the service in question will mention
whether the signal is used or not. I mean, if I'm writing a D-Bus
client that speaks to udisks then I read the docs

http://hal.freedesktop.org/docs/udisks/Device.html

to know what ABI to interact with. For example, I know that with this
particular udisks ABI, I need to connect to the Changed() D-Bus signal
and do a Properties.GetAll() whenever I receive that signal (yup,
that's a bit ineffective but that's the way it works...).

Similarly, the upcoming version of udisks will use this new stuff and
then I, as an application programmer using udisks, will know that I
can simply listen to PropertiesChanged() to listen for changes to
properties (and thus avoid the constly GetAll() call).

One upside about standardizing this signal is that D-Bus bindings can
actually do something sensible now. For example, in the new GLib D-Bus
bindings that I'v been working on does, the GDBusProxy class does the
following (except if DO_NOT_LOAD_PROPERTIES is passed as a
construction flag)

 connect to PropertiesChanged()
 invokes Properties.GetAll()

which means that I, as an application programmer, can use non-blocking API like

 GVariant *value;
 value = g_dbus_proxy_get_cached_property (proxy, "PropertyName", &error);

to get the property. It means that it suddenly got 100 times easier to
actually interact with remote services (such as udisks) that use D-Bus
properties.

Cheers,
David