GDBus: Omit PropertiesChanged signal and add match rule

[David Zeuthen]

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