GDBus: Omit PropertiesChanged signal and add match rule
David Zeuthen
zeuthen at gmail.com
Fri Mar 9 08:14:46 PST 2012
Hi,
On Fri, Mar 9, 2012 at 3:46 AM,
<Jean-Pierre.Bogler at continental-corporation.com> wrote:
> 1. When I use a 'D-Bus property', I noticed that a signal is send everytime
> I change its value. The D.-Bus specification says that
> I can omit this sending using the annotation
> 'org.freedesktop.DBus.Property.EmitsChangedSignal'. Unfortunately GLib
> doesn't seem
> to support this annotation or did I miss something?
I don't think the core GDBus routines (e.g. what is in libgio-2.0.so)
will never automatically emit the PropertiesChanged signal, but
skeleton objects generated by gdbus-codegen(1) indeed will. I'm
guessing this is what you are using?
IIRC, right now gdbus-codegen(1) does not look at the
org.freedesktop.DBus.Property.EmitsChangedSignal ... but it certainly
could. File a bug against GLib, component gdbus with the request
please?
> 2. The clients waiting for the signals are not interested in every System-
> or SessionState. Therefore I want send the signal with the first
> the Session- or StateName (string) as first argument and apply a match rule.
> Is this a good programming praxis?
Yeah, seems fine to me - there's certainly a lot of other D-Bus APIs
that do this.
> 3. This is not a D-Bus topic, but maybe you can help me: Do you know a good
> place to learn the insights of the GMainloop?
My guess is that
http://developer.gnome.org/glib/unstable/glib-The-Main-Event-Loop.html
is your best bet.
> For example I still wonder how
> g_mainloop_new, g_signal_connect and g_mainloop_run are working. From the
> passed parameters I can see no connection between the D-Bus object and the
> loop. Furthermore I noticed that the signals seem to be queued (I fired
> multiple of them on the main loop, while another one was processd.). Is this
> queue limited?
Nope, the queue of idles (or any other GSource) is not limited.
Generally, any routine in GDBus (and the rest of GIO for that matter)
has documentation saying where the callback will happen which is one
of
1. in the thread-default main loop at the time of calling the
routine, for example
http://developer.gnome.org/gio/unstable/GDBusConnection.html#g-dbus-connection-call
http://developer.gnome.org/gio/unstable/GDBusConnection.html#g-dbus-connection-signal-subscribe
http://developer.gnome.org/gio/unstable/GDBusConnection.html#g-dbus-connection-register-object
http://developer.gnome.org/gio/unstable/GDBusProxy.html#g-dbus-proxy-call
or
2. in the thread-default main loop where the object was constructed,
for example
http://developer.gnome.org/gio/unstable/GDBusConnection.html#GDBusConnection-closed
http://developer.gnome.org/gio/unstable/GDBusProxy.html#GDBusProxy-g-properties-changed
http://developer.gnome.org/gio/unstable/GDBusProxy.html#GDBusProxy-g-signal
3. The default main-loop (e.g. the main loop of the main thread,
typically the GUI thread), for example
http://developer.gnome.org/gio/unstable/GNetworkMonitor.html#GNetworkMonitor-network-changed
where "thread-default mainloop" is defined here
http://developer.gnome.org/glib/unstable/glib-The-Main-Event-Loop.html#g-main-context-push-thread-default
As you can see it's pattern 1. is the most used pattern.... for things
GLib signals, it's generally 2.... when dealing with singletons, you
typically use 3.
Hope this helps.
David
More information about the dbus
mailing list