[pygtk] Re: Re: Cannot subclass gtk.Widget

Gustavo J. A. M. Carneiro gjc at inescporto.pt
Mon Mar 12 22:20:11 WST 2007


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
<gjc at inescporto.pt> <gustavo at users.sourceforge.net>
The universe is always one step beyond logic.



More information about the pygtk mailing list