Menu
▾
▴
gtk2-perl-bugs
|
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2011-10-20 05:29:13
|
https://bugzilla.gnome.org/show_bug.cgi?id=662265 gnome-perl | Glib | unspecified Summary: gperl_value_from_sv() doesn't understand G_TYPE_VALUE_ARRAY values Classification: Bindings Product: gnome-perl Version: unspecified OS/Version: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: Glib AssignedTo: gtk...@li... ReportedBy: mic...@gm... QAContact: gtk...@li... GNOME version: --- Created an attachment (id=199499) --> (https://bugzilla.gnome.org/attachment.cgi?id=199499) GPerlBoxedWrapperClass for G_TYPE_VALUE_ARRAY I'm wrapping a GObject-based library with a couple of objects that have array properties (GParamSpecValueArray). When I try to set the property on construction, I get the following error: internal problem: GType GValueArray (2535808) has not been registered with GPerl This seems to be due to the fact that GValueArray is a boxed type, but it has not been registered with gperl_register_boxed, and there isn't any special code to handle ValueArray values in gperl_value_from_sv(). I needed a work around to get some minimal functionality for the library bindings, so I implemented the attached code, which I include in the library bindings module itself. This code probably isn't correct (I've only tested it for integers in the SV-to-GValue direction), and a proper fix should probably be to implement handling of value arrays at some point higher in the call stack (say when decoding the property GParamSpecs). -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
|
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2011-10-20 22:31:34
|
https://bugzilla.gnome.org/show_bug.cgi?id=662265 gnome-perl | Glib | unspecified Michael Culbertson <michael.culbertson> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #199499|0 |1 is obsolete| | --- Comment #1 from Michael Culbertson <mic...@gm...> 2011-10-20 22:31:21 UTC --- Created an attachment (id=199593) --> (https://bugzilla.gnome.org/attachment.cgi?id=199593) GPerlBoxedWrapperClass for G_TYPE_VALUE_ARRAY Fixed some of the work-around code. Has been tested SV->GValue and GValue->SV for int, string, and GObject. -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
|
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2011-10-23 22:04:25
|
https://bugzilla.gnome.org/show_bug.cgi?id=662265 gnome-perl | Glib | unspecified Torsten Schoenfeld <kaffeetisch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kaf...@gm... --- Comment #2 from Torsten Schoenfeld <kaf...@gm...> 2011-10-23 22:04:14 UTC --- The GValue→SV part looks fine basically, but it should use g_value_array_get_nth and g_value_array_free. But as you note the trouble is with the the SV→GValue part. One simply cannot reliably know what type an SV has -- think of overloading, for example; <http://markmail.org/thread/xqab2x34q3kjm4l4> has more details. Also, Perl programmers don't expect to have to use things like 0+$value just because some function expects a number. The only safe way to do this, as far as I can see, is if you already know somehow what type is expected. This is the case for gtk_list_store_set_value, for example: you can find out the expected type by finding the column's type. So, what API are you trying to wrap? Is there a way to know the expected type? -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
|
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2011-10-24 00:13:28
|
https://bugzilla.gnome.org/show_bug.cgi?id=662265 gnome-perl | Glib | unspecified --- Comment #3 from Michael Culbertson <mic...@gm...> 2011-10-24 00:13:13 UTC --- I'm wrapping the OSCATS library (http://code.google.com/p/oscats), which includes an element param spec for the array-valued properties (#GParamSpecValueArray.element_spec), so the expected type for the elements of is known, at least at the point at which the property information has been accessed---such as in: GObject.xs:g_object_new() GObject.xs:init_property_value() GParamSpec.xs:g_param_value_validate() GParamSpec.xs:g_param_values_cmp() It would probably be better to handle the G_TYPE_VALUE_ARRAY case there, instead of in a boxed wrapper, as I did in the work-around, at least for the SV->GValue direction. -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
|
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2011-10-24 19:33:58
|
https://bugzilla.gnome.org/show_bug.cgi?id=662265 gnome-perl | Glib | unspecified --- Comment #4 from Torsten Schoenfeld <kaf...@gm...> 2011-10-24 19:33:45 UTC --- (In reply to comment #3) > I'm wrapping the OSCATS library (http://code.google.com/p/oscats), which > includes an element param spec for the array-valued properties > (#GParamSpecValueArray.element_spec), so the expected type for the elements of > is known, at least at the point at which the property information has been > accessed---such as in: I see. (But note that element_spec is documented as allowing NULL.) > GObject.xs:g_object_new() > GObject.xs:init_property_value() > GParamSpec.xs:g_param_value_validate() > GParamSpec.xs:g_param_values_cmp() Yeah, gperl_value_from_sv is not among them. I guess we need to alter Glib::Object::set_property to somehow cooperate with init_property_value such that gperl_value_from_sv knows the expected element type when it encounters a boxed of type G_TYPE_VALUE_ARRAY. That won't cover G_TYPE_VALUE_ARRAY arguments to signals or similar, but I don't see how to handle that automatically. -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
|
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2011-10-24 20:23:30
|
https://bugzilla.gnome.org/show_bug.cgi?id=662265 gnome-perl | Glib | unspecified --- Comment #5 from Michael Culbertson <mic...@gm...> 2011-10-24 20:23:17 UTC --- It's true that element_spec can be NULL, in which case one is sort of out of luck (seems like poor object specification, in my view), but if the property specification supplies the element type, it seems reasonable to make use of it. Although it probably isn't possible to handle the arguments to signals and other closures automatically now, it probably would be through GObject Introspection (for well-documented objects, at least), once it becomes a little more mature. -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
Thanks for helping keep SourceForge clean.
X