[gst-devel] Re: [gst-cvs] wingo gstreamer: gstreamer/ gstreamer/gst/ gstreamer/testsuite/ gstreamer/testsuite/ghostpads/

[David I. Lehn]

* Andy Wingo <wingo at pdx.freedesktop.org> [2004-02-05T09:55:12-0500]:
> 2004-02-05  Andy Wingo  <wingo at pobox.com>
> 	* gst/gstpad.c (_gst_real_pad_fixate_accumulator):
> 	s/pointer/boxed/.
> 	* gst/gstmarshal.list (VOID:BOXED, BOXED:BOXED): New marshallers.
> 	* gst/gstpad.c (gst_real_pad_class_init): Use a BOXED:BOXED
> 	marshaller for ::fixate, and VOID:BOXED for ::caps-nego-failed,
> 	with the type=GST_TYPE_CAPS. This allows language bindings to know
> 	what kind of data they're dealing with.
> 	* gst/gstcaps.c (_gst_caps_value_init): GBoxed values initialize
> 	to NULL when g_value_init is called. GstCaps, which rolls its own
> 	type implementation, now does the same instead of allocating empty
> 	caps.

I'm a bit confused by these marshal issues.  I was looking at a similar
issue the other day for GstElement "found-tag" signal.  It passes a
GstTagList as a POINTER type.  This causes the same bindings issue.  It
can't determine the type of the data.  C code just does an arbitrary
cast by accepting a GstTagList* in the function call.  Python code is
just screwed.  The _only_ way I can think of to solve this in the Python
case is to have a custom pointer2taglist() function call or something
that unwraps the pointer wrapper and rewraps it as a taglist (or
gststructure really).  That's really ugly to have to call specialized
functions like that.  And it looks like exactly what the marshalling
code is supposed to do.

ds says this is how marshalling is supposed to work and value types are
not supposed to be used to determine real value types.  This seems
totally bogus.  I understand there is an issue with having to copy the
objects around but isn't that the point?

So how is this supposed to work?  Should we have all the signals declare
real types rather than pointers and just deal with copy issues some
other way?  From a bindings perspective using proper types is the proper
way to do things.  Code like Gtk seems to agree.  If pointers are the
right way then why do so many other signals use non-pointer types?

-dave