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

Colin Walters walters at verbum.org
Sat Feb 12 19:07:01 PST 2005


On Sat, 2005-02-12 at 16:20 -0500, Havoc Pennington wrote:
>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.

I'm working towards doing that now actually.  I'm probably going to run
glib-genmarshal from within dbus-binding-tool.

>> 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.

Makes sense.

>Some suggestions on the patch you posted earlier:
> - c_name is still an attribute in dbus-gparser.c

Yeah, that'll go away when we do annotations.

> - can we put the C code generation in a separate file? dbus-output-
>glib.c 

Done in my current patch.

> - go ahead and implement the <annotation> thing I think, and be sure
>   this is noted in dbus-specification.xml

Haven't started on this yet, but it's next on the list.  I realized that
we also need the annotations right now also for sensibly mapping GErrors
(in particular the code) to dbus error message names.  Of course this'll
all be fixed when we get real GObject introspection.

>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...

Ok, well...I have a massively rewritten patch about halfway through.
Without the annotations it isn't too bloated (at least so far).  I'll
send it along either tonight or tomorrow; it should be a much better
fundamental basis.  Once it's reviewed, we can make conceptually
orthogonal changes such as annotations separately.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/dbus/attachments/20050212/2d5c08d2/attachment.pgp


More information about the dbus mailing list