Re: could not find signal invocation hint

[James Muir <hemlock vtlink net>]

muppet wrote:

> $self->SUPER::ripen; # does what you want.
Thanks for cutting through my confusion. I gotta check my PANEXA 
prescription :-) . I was and probably still am mis-reading the 
Glib::Object::Subclass and the "Subclassing Widgets in Perl" documents.

I'm unclear as to what the following section from the 
Glib::Object::Subclass document is trying to tell me. Are the "Base 
Methods" the INIT_INSTANCE, SET_PROPERTY etc methods or just any widget 
method such as 'size_request'? I understand that signals allow for a 
class closure (nice feature), but I'm confused as to how or why events 
come into the picture at all for overriding methods. The Gtk2::Widget 
class has a 'size_request' method, so it seems that the name of the 
method is being placed into the signal hash and it references a 
subroutine to override the method. Is this to work around Glib issues? 
Not sure when it is appropriate to use the scheme described below to 
override a method. Thanks for your help in clarifying this.


   OVERRIDING BASE METHODS

GLib pulls some fancy tricks with function pointers to implement methods 
in C. This is not very language-binding-friendly, as you might guess.

However, as described above, every signal allows a "class closure"; you 
may override thie class closure with your own function, and you can 
chain from the overridden method to the original. This serves to 
implement virtual overrides for language bindings.

So, to override a method, you supply a subroutine reference instead of a 
signal description hash as the value for the name of the existing signal 
in the "signals" hash described in SIGNALS 
<http://gtk2-perl.sourceforge.net/doc/pod/Glib/Object/Subclass.html#SIGNALS>. 


 # override some important widget methods:
 use Glib::Object::Subclass
       Gtk2::Widget::,
        signals => {
                expose_event => \&expose_event,
                configure_event => \&configure_event,
                button_press_event => \&button_press_event,
                button_release_event => \&button_release_event,
                motion_notify_event => \&motion_notify_event,
                # note the choice of names here... see the discussion.
                size_request => \&do_size_request,
        }