C convenience lib (was Re: Is dbus_pending_call_set_notify() thread safe?)

[nf2]

Thiago Macieira wrote:
> nf2 wrote:
>   
>> Of course! But why can't QtDBus optionally use "gbus" or even the
>> DBUS-GLib-Bindings when compiled with glib main loop integration?
>>     
>
> Because there's no point in doing so.
>
> 1) it would be an extra library loaded. I don't want that.
> 2) it would provide no extra features.
> 3) it would provide extra work for me to maintain.
> 4) it _cannot_ integrate with the libdbus-glib-1 main connection *anyways* 
> (read: we cannot get rid of the private connection)
>
> All of this for something that would be better solved in libdbus-1? No, 
> thanks.
>   
Hmm ... following your discussion has been quite interesting. Although i 
didn't understand all of it.

For instance i didn't know that QtDBus only uses private connections. Is 
that right? Thus if Qt or KDE uses GLib based libraries which use the 
shared connections, there won't be any problem (if Qt is compiled with 
GLib-Main-Loop. Having multiple connections to the session daemon might 
be a bit inefficient - but at least it works - and there won't be more 
than two connections, because all the KDE/Qt stuff will use the private 
QtDBus session bus connection and the rest will use the shared connection).

If there is something special about how QtDBus uses it's private 
connections. Could it be fixed without breaking the QtDBus API, and Qt 
could also use the shared connections? (just to avoid having two 
connections?)

Another thing i didn't know is how the dbus watches work. For instance 
that you can call dbus_connection_set_watch_functions() on a connection 
multiple times, so that every library can bring its own main-loop glue 
(Which will usually do the same thing, assuming that GLib-Main-Loop is 
the standard main loop - which - i believe - it should be in Linux/Unix 
anyway ). When dbus_connection_set_watch_functions() is called again, 
all the old watches will be removed from the connections filedescriptor. 
is that correct?

One thing i don't understand is: does every main-loop glue always have 
to live until the end of the application process? Why is there no stack 
of watch function sets for every connection. Lets consider two libraries 
using the shared session bus connection (and bringing their own main 
loop glue)

1) ......A-----------------------------B.............
2) ............C----------------D..................

---->time

As far as i understand things, now the mainloop-glue from library 1 is 
used from A to C, and the mainloop-glue of library 2 from C to B! 
Instead i believe that after D the mainloop glue of library 1 should be 
used again. (after 2 has unref'ed the connection). But i guess this 
would require returning a connection handle instead of the actual 
connection in dbus_bus_get().

Norbert








Norbert