[patch] generate marshallers and metadata from dbus-glib-tool

Havoc Pennington hp at redhat.com
Sat Feb 12 13:20:15 PST 2005


On Sat, 2005-02-12 at 15:58 -0500, Colin Walters wrote:
> It seems to me, after looking at this a bit, that the same dbus message
> signature should map to a different marshaller for method calls versus
> signal callbacks, because method calls should (by default) return a
> boolean and take a GError as a final parameter, which are not
> represented in the message signature.  Additionally, method calls can
> have OUT parameters.  

Sounds right. Well... we could generate marshalers BOOL__BLAH_ERROR and
still use glib-genmarshal I suppose. But that might not be worth it.

> So I'm not sure that much more code can be shared between the two cases.
> Or am I missing something?

I think the important thing to share is the conversion from DBusMessage
to array of GValue (and vice versa), because we want to be sure the same
set of conversions is supported in all cases. So this is probably OK
already just with dbus-gvalue.c I guess.

Some suggestions on the patch you posted earlier:
 - c_name is still an attribute in dbus-gparser.c
 - can we put the C code generation in a separate file? dbus-output-
glib.c 
   or something. idea is to have dbus-output-*.c
 - go ahead and implement the <annotation> thing I think, and be sure
   this is noted in dbus-specification.xml

With those changes I think it's fine to commit and iterate from there,
it's not like the code works now and I don't want to review a huge patch
all at once...

Havoc




More information about the dbus mailing list