glib encapsulation patch
hp at redhat.com
Fri Jun 18 12:23:34 PDT 2004
On Fri, 2004-06-18 at 10:36, Olivier Andrieu wrote:
> Havoc Pennington <hp at redhat.com> [Thu, 10 Jun 2004 23:45:23 -0400]:
> > Hi,
> > I didn't commit this yet, want to think about it a bit more.
> > What do people think?
> > It's not quite complete, since the GLib bindings aren't quite complete.
> > Notably all the varargs stuff isn't redone to fully use G-types, signal
> > marshaling is left hanging, etc. And of course you still can't implement
> > a server since dbus-glib-tool isn't done.
> What would be the API like with signals ? smthg like that:
> dbus_gproxy_connect_signal(proxy, "Foo", "us", G_CALLBACK (handler));
> "us" being the signature and the handler would be:
> void handler (DBusGProxy*, guint32, gchar *)
That's the obvious API, I didn't like that very much since "us" is a
pretty obscure string to have to type. I'm trying to figure out what to
One option is that we introspect the signal and get the signature,
similar to what Python bindings etc. will do.
Another approach might be something like:
connect_signal (proxy, "Foo", G_CALLBACK (handler), data, G_TYPE_UINT,
That one feels nicest to me on some level.
More information about the dbus