GNOME Bugzilla – Bug 539055
Gst*Pad* new functions don't initialze the object's instance with the construction properties.
Last modified: 2008-06-20 15:04:37 UTC
I was just reading the GObject docs and found the following (see http://library.gnome.org/devel/gobject/2.17/chapter-gobject.html#gobject-instantiation): Object instantiation The g_object_new family of functions can be used to instantiate any GType which inherits from the GObject base type. All these functions make sure the class and instance structures have been correctly initialized by glib's type system and then invoke at one point or another the constructor class method which is used to: * Allocate and clear memory through g_type_create_instance, * Initialize the object' instance with the construction properties. I'm still working on C++ bindings (gstreamermm) and am encountering problems with some of the *_new* functions, particularly the ones pertaining to the Gst*Pad* objects because the GObjects are not initialized with the construction properties (for example "name" and "direction" properties for gst_pad_new(), etc.). Is there a reason the GObjects are not initialized with the construction properties? Would it be difficult to fix? Is it contemplated to be fixed? Thanks.
Can you provide some example code that you think initializes a pad incorrectly?
I'm using code like new_pad = GST_PAD_CAST (g_object_new (GST_TYPE_CUSTOM_PAD, "name", pad_name, "direction", templ->direction, "template", templ, NULL)); at several places without any problems. Some example code that fails would really help :)
It's not an error per se, it's just that in our C++ wrapping library the scripts we use to bind the C code in specific cases (mostly where the wrapping of GObject classes are concerned) generate automatic constructors that try to create the underlying GObjects by getting the GType's GTypeClass structure with g_type_class_ref(), creating a GParameter array of the construction properties (they try to find the properties with g_object_class_find_property() first to make sure that they exist) and then creating the GObject with g_object_newv(). When the properties are not found, for example when creating a Gst::Pad with a name/direction constructor (which in your API would probably be done with a call to gst_pad_new()) we get a warning as follows: (lt-test-pad:19579): glibmm-WARNING **: Glib::ConstructParams::ConstructParams(): object class "gtkmm__GstPad" has no property named "dir" because the constructor is not able to find the construction property "dir" (the second parameter of the constructor). Are we going about this the wrong way? Is using g_object_newv() in this case inappropriate and would it be best to somehow directly use the gst_*_pad*_new*() functions? I'm trying to get a sense of what's possible, correct and appropriate in providing C++ bindings of your fine API. Thanks very much.
Did you mean to use "direction" instead of "dir"? GstPad doesn't have a "dir" property.
Thanks. I knew I had something wrong. Using "direction" instead of "dir" with Gst::Pad makes the warning disappear. Looking at the GstGhostPad gst_ghost_pad_new_no_target() function, it has a "dir" parameter (I was under the impression, obviously in error, that the property names could be taken from the parameter name -- sorry), I guess I would use "direction" for that property also Right? This may be a simple question, but the answer would help a lot (I realize I don't know in detail about GStreamer internals, but I'd really like to try to provide C++ bindings if possible and also learn as I go): How can I find the constructor property names for example for GstGhostPad (Am I right in assuming that it would have properties such as "templ" for its GstPadTemplate and "target" for its GstPad target)? Thanks for your help.
> I was under the impression, obviously in error, that the property names could > be taken from the parameter name -- sorry Normally they are, though it's just an informal convention. It's easy for us to workaround when they differ, by hand-coding the implementation in our .ccg file, using the _CONSTRUCT() macro, as you'll see in many gtkmm .ccg files. > How can I find the constructor property names for example for GstGhostPad You can look at the implementation of the _new() functions, looking for the call to g_object_new(). But when they do much more than call g_object_new() then that's a bug in the C library. For instance: http://bugzilla.gnome.org/show_bug.cgi?id=539108 See also http://gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/sec-wrapping-problems.html#wrapping-no-properties I suggest that you close this bug unless you have a problem with a specific C function. So far it's unlikely to make much sense to the gstreamer developers.
Ok, let's close this one then and handle specific cases in separate bugs like bug #539108.
(In reply to comment #6) > > I was under the impression, obviously in error, that the property names could > > be taken from the parameter name -- sorry > > Normally they are, though it's just an informal convention. It's easy for us to > workaround when they differ, by hand-coding the implementation in our .ccg > file, using the _CONSTRUCT() macro, as you'll see in many gtkmm .ccg files. > > > How can I find the constructor property names for example for GstGhostPad > > You can look at the implementation of the _new() functions, looking for the > call to g_object_new(). But when they do much more than call g_object_new() > then that's a bug in the C library. For instance: > http://bugzilla.gnome.org/show_bug.cgi?id=539108 > > See also > http://gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/sec-wrapping-problems.html#wrapping-no-properties > I stand corrected. Thanks.