glib encapsulation patch

[Olivier Andrieu]

 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
 > do.
 > 
 > 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));
with 
  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,
 > G_TYPE_STRING)
 > 
 > 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*'.

-- 
   Olivier