Re: GDBus/GVariant plans for next GLib release
- From: Alexander Larsson <alexl redhat com>
- To: David Zeuthen <david fubar dk>
- Cc: Ryan Lortie <desrt desrt ca>, mclasen redhat com, gtk-devel-list gnome org, Havoc Pennington <havoc pennington gmail com>, Robert McQueen <robert mcqueen collabora co uk>
- Subject: Re: GDBus/GVariant plans for next GLib release
- Date: Fri, 06 Nov 2009 21:05:35 +0100
On Wed, 2009-10-14 at 21:34 -0400, David Zeuthen wrote:
I just read through this for basic review, and I must say that I like
it. Very nice stuff. Some comments:
In nautilus I'd like to have an object path which is basically a pointer
to another object. Say I have these objects:
Then i want something like:
That always points to the view object in the active tab.
Now, i could constantly be re-creating this object all the time, but
thats not really very nice. What i instead want to do is basically
register a subtree at /nautilus/window/1/active_view which dynamically
looks up which tab is active and then re-routes to the right tab.
To implement this cleanly I would need to be able to lookup an object at
a given path (returning the ifaces, vtables and user data) and to
enumerate the children of a given path. All this would be in-client
registered objects/subtrees only, and is enough to implement
GDBusSubtreeVTable for the "pointer subtree".
I don't see any call to dbus_threads_init() or
dbus_threads_init_default(). Surely this should be done if gthread is
enabled. Ideally in g_thread_init_glib(), but thats a bit hard for
something in libgio...
I'd like it to be possible to specify a non-default main context when
creating a connection with g_dbus_connection_new() or
g_dbus_connection_send_dbus_1_message_with_reply() has a race condition
if called on a thread other than the one dispatching the reply. The
pending call may be completed before dbus_pending_call_set_notify() is
reached. See _g_dbus_connection_call_async in gvfs/common/gdbusutils.c
for a possible workaround.
The way e.g. properties are implemented is very static. There is no way
to expose an object with a dynamic set of properties (apart from
removing and re-adding the object with new introspection data each time
dynamic properties/methods can't be implemented? (lazy, i.e. not remove
and re-add each time they change). I guess this is sort of weird wrt how
dbus usually works, but might be useful when exporting an object from a
Maybe we should not claim to implement org.freedesktop.DBus.Properties
if set/get_property are NULL?
I'm not sure if I missed it, because i didn't try it out, but how do
registered object with a a child that is specified by registering a
subtree get enumerated when introspecting the registered object?
The foo_bar_error_quark example in gdbuserror.c clearly should just call
a standard helper that does all this, just given the pointer to an array
Why use a hex encoding for the quark name? Most gerror quark names are
quite readable, and it would be nice to preserve this in the encoding
There are no bindings for dbus_connection_flush, which might be nice to
e.g. ensure that the reply sent from a message handler is immediately
sent since we may block or whatnot later. Maybe we want this?
gdbusnameowning.c:request_name_cb() - Isn't it racy to not subscribe to
NameLost/NameAquired until we're processing the request name reply?
We could have gotten a NameLost message inbetween the RequestName reply
gotten and request_name_cb being handled by the mainloop, as the
request_name_cb is called from another idle.
g_dbus_server_new() wants a way to specify the GMainContext to use.
gdbusprivate.c has a bunch of code with a copyright notice from dbus
that is AFL 2.1 or GPL2+. I.e. not LGPL. This seems like a problem for
Are you aware of:
#define G_PARAM_STATIC_STRINGS (G_PARAM_STATIC_NAME |
G_PARAM_STATIC_NICK | G_PARAM_STATIC_BLURB)
It saves some typing.
] [Thread Prev