On Sex, 2007-03-09 at 11:05 -0500, John Dennis wrote:
> On Fri, 2007-03-09 at 10:38 -0500, John Dennis wrote:
> > On Fri, 2007-03-09 at 08:10 -0700, Jeffrey Barish wrote:
> > > Gustavo J. A. M. Carneiro wrote:
> > >
> > > > Another, more complex, example can be found here:
> > > > http://telecom.inescporto.pt/~gjc/higcontainer/higcontainer.py
> > >
> > > Thanks to everyone for the examples. Is there documentation anywhere on
> > > the
> > > do_ methods that they all contain? I guess that when a Widget receives a
> > > size_request call, for example, it calls do_size_request on its children.
> >
> > My understanding, albeit gleaned only from example code and
> > experimentation is widget subclassing in pygtk works by the following
> > method. Instead of overriding a method by creating a new method in the
> > subclass with the same name as is the normal method of subclass override
> > in OO languages pygtk appears to operate this way: The name of the
> > method is prefixed with 'do_' and a method look up is performed on that
> > name in the subclass, if the do_xxxx method is found it is invoked as
> > the overridden method. If the override mechanism does not work this way
> > I'd love to know what actually is going on. I'm also curious as to why
> > pygtk seems to have this peculiar and undocumented subclassing form.
> >
> > To the best of my knowledge the 'do_' prefix method of subclassing is
> > totally undocumented in pygtk other than it appears in the example code.
> > I searched for hours looking for a clear statement of the subclassing
> > behavior and I never found it. To my mind this is a serious
> > documentation omission.
>
> Could it be that 'do_' method naming is not subclassing but rather
> auto-magic signal connecting via method naming convention? Either way, I
> never did find any documentation on it.
The do_xxxx are called in two different situations:
1. When the user overrides a signal (__gsignals__ = {'xxx':
'override'}); In this case the do_xxx method becomes the default signal
action;
2. When a class Foo has a virtual method (function pointer "yyy (*xxx)
(...)" in the FooClass) then if PyGTK "supports" overriding this virtual
method [1] then any Foo subclass that is gobject.type_register()ed will
look for a method do_xxx in the subclass and if found replaces registers
it as implementation for the xxx virtual method.
1 and 2 are mutually exclusive, and 1 always takes precendence (when a
signal is overridden, virtual method override is inhibited).
This is probably not documented. But of course patches are welcome..
[1] not all of them are supported; only by looking at the generated C
code can you tell whether a particular method is supported or not.
--
Gustavo J. A. M. Carneiro
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
The universe is always one step beyond logic.
_______________________________________________
pygtk mailing list pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
