glib encapsulation patch
oliv__a at users.sourceforge.net
Mon Jun 21 01:57:51 PDT 2004
Havoc Pennington [Fri, 18 Jun 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.
Hmm but we still need a way to check that the signature of the
incoming message is compatible with the one implemented by the
callback. If we use simply
dbus_gproxy_connect_signal(proxy, "Foo", G_CALLBACK (handler));
void handler (DBusGProxy*, guint32, gchar *);
and if the incoming signal is in fact of another signature (but in
agreement with introspection data), everything would crash.
> 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.
Maybe but the with signature string it's also nice to be able to
#define it or put it in a `static const gchar*'.
More information about the dbus