GNOME Bugzilla – Bug 642535
gst_parse_launch fails on pointer parameters
Last modified: 2011-04-22 03:26:11 UTC
I've written a gstreamer plugin that takes a gpointer as a construction parameter (g_param_spec_pointer(...)), however when I pass the address in either decimal or hex to the parameter using gst_parse_launch, it fails with: glib.GError: could not set property "pointer-property" in element "plugin-name0" to "0x3c6a650" It is calling my set_property function, but still throws an error anyway. Everything works fine when I install the parameter as g_param_spec_ulong and cast it to a pointer in set_properties, but it should work with pointer parameters too (which would also be more 64-bit safe). I think that parser/grammar.y isn't looking for pointers the way it should be.
I don't know how much sense it makes to add that. Are you using printf/g_strdup_printf or so to create a string with a pointer-string? I think a better approach would be: gst_parse_launch ("... ! yourelement name=foo ! ...", ...) myfoo = gst_bin_get_by_name (pipeline, "foo"); g_object_set (myfoo, "pointer-property", ptr, NULL); (also, a boxed type property is generally prefered to a pure pointer property).
Well, I'm actually using gst_parse_launch through pygstreamer. And pygtk doesn't all you to create GBoxed or GPointer from an address. So the g_object_set/set_property technique won't work. To get the address, I'm using the method of another python class that returns the baseaddress of the C struct it wraps. But it returns it as a number, not a gpointer, since it can't depend on pygtk/gobject. Is adding the ability to parse_launch pointers really difficult?
It's not difficult, but it's generally considered pretty broken API, especially for bindings, so I'm not convinced it's worth adding support for it. What are you passing here exactly?
I don't think it is worth fixing that too. Also reporter seems to have solved this now differently. Thus closing.