enum/flag package registration? (was Re: Missing pango constants)

["muppet" <scott asofyet org>]

requests for those reading along:  while i ponder under-the-hood fixes, can
anybody suggest a perl-only workaround?  are there any other situations where
this sort of problem crops up?


Torsten Schoenfeld said:
> I see. Forget about the patch then and please consider this bug report
> instead: The above magic somehow doesn't apply to PangoStyle values.
>
> When used in a TreeView whose "style" attribute is bound to a
> Glib::String column and you populate this column with "normal" or
> "italic", a warning is issued:
>
>   (odot:23383): GLib-GObject-WARNING **: unable to set property `style'
>   of type `PangoStyle' from value of type `gchararray'

well, this is a whole different ball of wax.  it's not that the magic doesn't
apply to the PangoStyle values --- you are tricking the type machinery!

you see, the string values used to represent enums and flags aren't *really*
strings; under the hood, they get translated to and from integers via a lookup
that depends on the GType of the enum or flag type in question.  this warning
actually comes from deep within the C libs when the objects try to
communicate; the cell renderer is looking for a GValue with a PANGO_TYPE_STYLE
enum value in it, but gets a GValue with a G_TYPE_STRING (or G_TYPE_CHARARRAY)
instead.

in essence, your column type is wrong, and should be Gtk2::Pango::Style type
instead of Glib::String type --- then the actual enumeration *value* (the
integer) will be stored in the tree model column instead of a string, with the
type identifier for validation, and everything should work out.

but that won't work, unfortunately.  when i set up the bindings i didn't
imagine that this would be a potential use for the enumerated types, so they
don't get registered into package names.  this shortcut saves startup time and
memory footprint; there are 143 of these types (out of 334 total) defined in
Gtk2 alone!  (see the file named "maps")

/me wracks brain trying to figure out how to solve this specific problem
without incurring a performance hit on the general case

are there any pure-perl workarounds that would avoid the problem?  what's some
more context on what you're doing --- is it the first way you'd think of doing
something, or is it sneaky wizzardry[1]?  (i ask because the obvious way needs
support, but wizardry might be able to suffer at the expense of performance.)

and, most importantly, can anybody think of other cases in which you can't get
by without (or things are incredibly simplified by) having perl package names
(which are the perl substitute for GLib GTypes) for GEnum and GFlags types?


> Sorry for the noise,

not noise -- discussion is good.  as you see, you uncovered something nasty.


[1] you know, like rincewind, with "wizzard" in silver letters on his pointy
hat. ;-)

-- 
muppet <scott at asofyet dot org>