On 12 August 2015 at 21:49, Torsten Schoenfeld <kaffeeti...@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 :-)
t2.pl
Description: Binary data
t3.pl
Description: Binary data
_______________________________________________ gtk-perl-list mailing list gtk-perl-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-perl-list
