Once we do this, I propose that there will be no use for the existing g_bus_watch_proxy() API (which in my opinion is annoying to use and racy for some use cases).

(In reply to comment #1)
> Once we do this, I propose that there will be no use for the existing
> g_bus_watch_proxy() API (which in my opinion is annoying to use and racy for
> some use cases).

I disagree. It combines getting the bus and getting a proxy (two blocking ops) into an easy-to-use API that is really hard to get wrong.

And I think adding that kind of API to GDBusProxy is a mistake and would uglify the API a lot. E.g. you are not going to get

 g_dbus_proxy_new_for_bus
 g_dbus_proxy_new_for_bus_finish
 g_dbus_proxy_new_for_bus_sync

in addition to the existing new function.

On IRC I mentioned that it would be beneficial to keep the combined API for the reasons you discuss.  I suggested this API:

void         g_bus_get_proxy        (GBusType              bus_type,
                                     ...etc...,
                                     GAsyncReadyCallback   callback,
                                     gpointer              user_data);

GDBusProxy * g_bus_get_proxy_finish (GAsyncResult         *result,
                                     GError              **error);

GDBusProxy * g_bus_get_proxy_sync   (GBusType              bus_type,
                                     ...etc...,
                                     GError              **error);

it's a nice match to the existing g_bus_* APIs, particularly g_bus_get().


Forcing people to use the explicit lifecycle API instead of the nicer API you described in this email just because they want a convenient one-step construction is an odd proposition.  May as well let people use the nicer object API *and* the nice construction API.

Fixed with this commit

 http://git.gnome.org/browse/glib/commit/?id=32f2e9a85beedeea36ac7623f68f6eb878465d44