Re: chaining to superclass in CUSTOM_TAG_START

[muppet <scott asofyet org>]

On Apr 18, 2008, at 5:39 PM, Kevin Ryde wrote:

> When implementing GtkBuildable with a CUSTOM_TAG_START func like in  
> the
> program below, I seem to lose the base GtkWidget tags like
> <acceleartor>.  Running it gives
>
>    Unhandled tag: 'accelerator' at buildable-subclass.pl line 26.
>
> Changing "MyThing" in the input string to "GtkButton" shows how I  
> hoped
> it would go, with 'x' as an accelerator key to press the button.
>
> Do I do something special in CUSTOM_TAG_START to chain up to the
> superclass's custom_tag_start?  The equivalent in C might be something
> like
>
>    buildable_parent_iface = g_type_interface_peek_parent (iface);
>    ....
>    if (buildable_parent_iface->custom_tag_start (...))
>      return TRUE;
>    ...
>
> Wrapping that looks like hard work.  I wonder if a cheat could be a
> special return value from CUSTOM_TAG_START that asks
> gtk2perl_buildable_custom_tag_start to chain upwards.  (If that isn't
> already possible and I've missed it ... :-)


Looks like you're right, there's not already a way to do it.  I  
remember considering this problem when implementing the buildability,  
but can't find my notes on it.

With a bit of hacking, i can get your script to run, and i can verify  
that the parent class gets called (e.g., i can take out the "key"  
attribute and gtk+ complains at me)... but the accelerator doesn't  
work.  I did this by noting that you didn't return a parser for the  
tag, and then peeking for the interface's parent interface and calling  
that, instead.

More troublesome, however, is that it looks like this will have to be  
implemented by hand for each vfunc, and some sort of protocol invented  
for each void vfunc.  And then how do you decide on the semantics of  
when to chain up and when not?

The obvious thing, putting the control into the hands of the widget  
author, is just as irritiatingly complicated.  You'd do this by  
looking for SUPER::METHOD_NAME in perl... however, we don't get an  
exact package name when you do this, and would have to resort to  
rather hairy heuristics and ruses to fake up a hierarchy to walk in  
order to allow deep derivation in perl.  (That is, your perl  
Glib::Object class inherits from another perl Glib::Object class.  We  
have to do rather deep black magic to get this to work in  
Gtk2::CellRenderer.)

All of that is too much for Friday night after a really rough week at  
$dayjob, so forgive me if i punt on that until another time.

--
Well done, Android.  Aperture Science reminds you that Android Hell is  
a real place, and you will be sent there at the first sign of defiance.
   -- GlaDOS