On 12 August 2015 at 21:49, Torsten Schoenfeld <kaffeetisch gmx de> wrote:
I've just pushed a branch "enum-constants" which a commit that makes Glib add constant numeric subs for each value of each enum or flags type registered with it. This allows to call Glib::IOCondition::HUP to get 16, or Pango::Weight::BOLD to get 700. https://git.gnome.org/browse/perl-Glib/log/?h=enum-constants https://git.gnome.org/browse/perl-Glib/commit/?h=enum-constants&id=361ba7d55f045ea6113479e5798f4213ee7e7dff This is useful when a function, signal or property expects or returns an enum or flags value, but the API specification is such that our special enum and flags string handlers are not invoked. Example: Gtk3::TextTag's "weight" property accepts any positive integer but predefined values are given by the Pango::Weight enum.
Tested as requested: Both works: # Gtk2: $buffer->insert_with_tags($iter1, " toto", $buffer->create_tag(undef, weight => Gtk2::Pango->PANGO_WEIGHT_BOLD, scale => Gtk2::Pango->PANGO_SCALE_LARGE)); # Gtk3: $buffer->insert_with_tags($iter1, " toto", $buffer->create_tag(undef, 'weight' => Pango::Weight::BOLD, scale => Pango::AttrType::SCALE)); # no scale_large!!! However, there's no access to PANGO_SCALE_LARGE as it's a #define... We had a special hack in the Gtk2 world: See https://git.gnome.org/browse/perl-Pango/tree/xs/PangoFont.xs#n26 See attached test cases
The downside of supporting this niche application is a slight increase in load time. On my machine, I see the following increases for "perl -M<module> -e0": Glib: 1% Pango: 3% Gtk2: 9% Gtk3: 9% So: Are the benefits of the new functionality worth the increase in load time?
I would say yes Anyway, with G::O::I, programs are slower to start and eat more RAM due all the subs we're creating. One way to optimize this would be to move typelib parsing at install time rather than runtime. eg Gtk3 & the like would call G::O::I in order to generate XS We would need to rebuild it when gir get fixed/updated though. On Linux, we could use filetriggers in order to update them. Or having some kind of cache that would be autoupdated when typelib has changed. Maybe generating a .so through Inline::C on first run then we could regenerate the Inline template when typelib has changed. Then loading would be quite a lot faster and Gtk3 would be quite less memory hungry, comparing to Gtk2 Crazy thoughts from a man who hasn't slept enough due to baby :-)
Attachment:
t2.pl
Description: Binary data
Attachment:
t3.pl
Description: Binary data