Signal for property changes
Marcel Holtmann
marcel at holtmann.org
Wed Dec 12 09:52:47 PST 2007
Hi Rob,
> >>> So what about adding a signal to the properties introspection that
> >>> allows us to do this officially? Something like
> >>>
> >>> org.freedesktop.DBus.Properties.Changed (STRING interface_name,
> >>> STRING property_name,
> >>> VARIANT value);
> >>>
> >>> Comments?
> >> Yes: the signal not being emitted must not mean the property did not
> >> change.
> >
> > actually if we have that signal, it should mean exactly that. If you use
> > the Set method to change the property, the signal should be emitted. In
> > case the property value is changed via a system event or an external
> > tool or whatever, the signal should also be emitted. This is the only
> > way to keep property values in sync with UI applications without polling
> > all the time.
> >
> > In case of BlueZ we do exactly this. For example if you use the command
> > line tool to change the friendly name (this goes directly via the kernel
> > interface) we still send out a signal that the name has changed.
> >
> > I can see that in some cases this is not always possible. So what about
> > adding that signal, but also having an annotation for the property value
> > that indicates that such a signal is available for this property. This
> > would also allow backward compatibility with the current specification.
>
>
> This is pretty much what I was about to propose for use in the D-Bus
> version of AT-SPI, so I'll happily help push this along :)
lets agree on naming for the signal and the annotation and then we
create a patch for upstream inclusion.
Regards
Marcel
More information about the dbus
mailing list