Re: RFC: Constant numeric subs for enum and flags values

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.

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 =>
# 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 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

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 :-)

Description: Binary data

Description: Binary data

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]