GNOME Bugzilla – Bug 591070
no support for GType/GParamGType
Last modified: 2010-05-16 12:23:25 UTC
currently, Glib does not support values and GParamSpec dealing with GType, thus it's impossible to deal with object properties storing a GType. rationale: Clutter has a class which stores an interval between two values, ClutterInterval; it would be probably more Perl-ish to override the bindings completely and write intervals as arrayrefs, but one of the nice bits of the class is that it allows subclasses to override the interval progress using their own progress function, e.g.: interval('boolean') = [ false, true ] compute(interval, progress=0.0) = false compute(interval, progress=0.2) = false compute(interval, progress=0.4) = false compute(interval, progress=0.6) = true compute(interval, progress=0.8) = true compute(interval, progress=1.0) = true myinterval('boolean') = [ false, true ] myinterval.threshold = 0.7 compute(myinterval, progress=0.0) = false compute(myinterval, progress=0.2) = false compute(myinterval, progress=0.4) = false compute(myinterval, progress=0.6) = false compute(myinterval, progress=0.8) = true compute(myinterval, progress=1.0) = true the type of the value of the interval is stored as a :value-type property in the C class, declared with g_param_spec_gtype(), since we allow interpolating the progress even between boxed types (e.g. colors or geometries). if I try to subclass ClutterInterval from Perl, and pass any value to the :value-type property at construction time, Perl, Glib and GLib will get *very* angry at me.
Created attachment 140129 [details] [review] Support GTypes in values and properties Currently, Glib is missing support for declaring Object properties storing GType (as package names), and for setting/getting those properties. The implementation of GParamSpecGType is pretty trivial, requiring only the registration of the GParamSpec and some glue for constructor and accessor to its only public member. The implementation of GValue support for GType is slightly more "interesting", since GType is *not* a fundamental type (like one would expect) but a sub-type of G_TYPE_POINTER. Fixes bug:
muppet created a similar patch many moons ago, and I recently committed it (without remembering this bug entry): <http://git.gnome.org/browse/perl-Glib/commit/?id=2b1a35b9d>. This old patch called the is_a_type accessor simply is_a_type(), which is inconsistent, so I just fixed that: <http://git.gnome.org/browse/perl-Glib/commit/?id=78696b6f8>. As far as I can see, the only remaining substantial difference between your patch and the committed version is this: --- a/GType.xs +++ b/GType.xs @@ -2018,6 +2018,7 @@ BOOT: gperl_register_fundamental (G_TYPE_FLOAT, "Glib::Float"); gperl_register_fundamental (G_TYPE_DOUBLE, "Glib::Double"); gperl_register_fundamental (G_TYPE_BOOLEAN, "Glib::Boolean"); + gperl_register_fundamental (G_TYPE_GTYPE, "Glib::GType"); gperl_register_boxed (GPERL_TYPE_SV, "Glib::Scalar", NULL); /* i love nasty ugly hacks for backwards compat... Glib::UInt used I'm not entirely sure what this achieves. Does it allow me to have, say, Glib::TreeView columns of type "Glib::GType"? If so, do we want to allow that? (We used to completely hide the existence of GType from the Perl programmer.) What else does this do?
I've committed this last difference now.