DBusConnection -> DBusGConnection woes

[Robert McQueen]

Havoc Pennington wrote:
> Hi,

Hola,

> For a given app it has to be defined which main loop is going to be
> attached to the shared dbus connections and how dispatch will work. All
> libraries the app is using have to be either configurable on this point,
> or in agreement with the app.

Right.

>snip reasonable justification<

>> There are howeber totally legitimate cases that Ross has found (being a
>> DBusServer for connections you wish to export GObjects on) that we are
>> failing to serve at the moment.
> 
> I don't think it should be complex to encapsulate this, though.

But I don't think it's necessary for us to try and encapsulate this.
He's already using the low-level libdbus API to do some of his work, and
libdbus-and-glib headers for other stuff, but there's no way to take a
connection that you set up in this world into the higher-level
DBusGConnection world. If we can decide a way to do that, we're sorted.

>> at the very least it would be good to make a
>> variant of setup_connection_with_g_main which returned you the
>> DBusGConnection, which would at least weakly guarantee that a
>> DBusGConnection was being dispatched via the glib mainloop.
> 
> I would say this is already guaranteed, except in the "people can do
> arbitrarily crazy things" sense. But, don't do that then.

Yes it's reasonably guaranteed currently, but I meant that we add the
API here as a way to lift people from the lower-level DBusConnection
(which you pointed dbus-glib at manually) to a DBusGConnection (which
you can export objects on and otherwise use normally).

> Havoc

Regards,
Rob