[PATCH] Add a parameterised gtype for structs

[Rob Taylor]

This patch looks good to me. That the glib tests pass without this is
slightly worrying :/

Thanks,
Rob Taylor

Ole André Vadla Ravnås wrote:
> Hi,
> 
> Here's a quick fix for a bug introduced in dbus-binding-tool by the
> struct patch. Basically the argument list for generated calls to
> dbus_g_type_get_struct ("GValueArray", ...) wasn't terminated.
> 
> Regards,
> Ole André
> 
> 
> On 2/7/06, Rob Taylor <robtaylor at floopily.org> wrote:
> 
>>[mm, forgot to reply to list.. damn mornings... ]
>>
>>Havoc Pennington wrote:
>>
>>>Ideally we could find a way to use the code in
>>>dbus-marshal-recursive-util.c to also test the glib stuff. It exports a
>>>function already (grep for generate_bodies) that returns all its test
>>>cases as raw data; if we could use that (or export some slightly
>>>different function) then the glib test suite could just get each test
>>>case, round-trip it through the glib bindings, and see if it gets back
>>>the same bytes as the original test case. Really this would be a pretty
>>>airtight way to test any binding.
>>
>>That's a very good idea, I think one thing we discussed with splitting
>>out the bindings was a unified way to unit test each binding, this seems
>>a good way of going about it.
>>
>>
>>>On the bigger picture of the patch - I think we had a discussion about
>>>how to do structs a while back? Any writeup of why this patch does it in
>>>this way vs. others, general notes on the approach, etc.?
>>
>>Well, as I saw it, there were two options for actually making the
>>bindings capable of marshalling every signature:
>>1) produce a true bijection from the glib type system to the dbus type
>>system
>>or
>>2) modify all marshalling recursion to also simultaneously descend the
>>dbus signature and marshal according to the signature.
>>
>>Now obviously the python and perl bindings use 2), as its more natural
>>for those languages to say how something should appear on the wire than
>>force users to do odd things to be strictly typed.
>>
>>However for glib, strict typing is completely natural, so 1) is the more
>>obvious choice. 2) would also have meant that several interfaces would
>>have to have changed (g_proxy_call, g_proxy_add_signal, etc), and that
>>we'd also have to store property and signal type information in
>>DBusGObjectInfo. TBH, it just seemed alien to the current modus operandi ;)
>>
>>Another option that I quickly discarded due to its foul nature ;) was to
>>modify all of the dbus-gsignature code so that it could also follow data
>>as well as the type in order to discover signature for structs as they
>>existed before this patch, but not only is this horrible, as I'm sure
>>you'll agree, it also doesn't help for the cases where, say an array is
>>empty.
>>
>>
>>
>>>Also, I asked Colin if he would take a high-level look at it.
>>
>>That would be brilliant - it was slightly scary doing this without his
>>input! ;)
>>
>>
>>Thanks,
>>Rob Taylor
>>
>>_______________________________________________
>>dbus mailing list
>>dbus at lists.freedesktop.org
>>http://lists.freedesktop.org/mailman/listinfo/dbus
>>
>>
>>
>>------------------------------------------------------------------------
>>
>>--- dbus/glib/dbus-binding-tool-glib.c-orig	2006-02-09 00:31:45.000000000 +0100
>>+++ dbus/glib/dbus-binding-tool-glib.c	2006-02-09 00:33:04.000000000 +0100
>>@@ -1072,7 +1072,7 @@
>>           g_string_append_printf (string, ", %s", value_lookup);
>>           g_free (value_lookup);
>>         }
>>-      g_string_append (string, ")");
>>+      g_string_append (string, ", G_TYPE_INVALID)");
>>       return g_string_free (string, FALSE);
>>     }
>>  
>>