Re: [pygtk] Re: Re: Cannot subclass gtk.Widget
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_ 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_ 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/
Re: [pygtk] Re: Re: Cannot subclass gtk.Widget
On Sáb, 2007-03-10 at 09:54 -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
>
> By studying the examples, I have learned a lot about subclassing. I have
> two questions about this example. It seems desirable to me that it be
> possible to call the subclass in the same manner used to call other PyGTK
> classes. Thus, in the case of your example, the subclass would be
> instantiated with
>
> group = HIGContainer(title='Hello')
>
> instead of
>
> group = gobject.new(HIGContainer, title="Hello")
>
> (In fact, I think it would be even more consistent to have
>
> group = HIGContainer()
> group.set_title("Hello")
group.set_title("Hello") is equivalent to group.props.title = "Hello",
and we all know there should be preferably only one way to do it ;-)
> )
>
> When I make this change, I get the error message
>
> 'HIGContainer' object has no attribute '_HIGContainer__title'
The error was caused by gobject setting the default property value.
>
> The error vanishes when I drop the gobject.PARAM_CONSTRUCT, so evidently
> gobject.new does something with __gproperties__ that does not happen
> otherwise. What is the implication of dropping the gobject.PARAM_CONSTRUCT
> flag and invoking the HIGContainer this way?
It was stupid of me to make that property gobject.PARAM_CONSTRUCT; it
means that the property can only be set during object construction,
through gobject.new, and also that if the property isn't explicitly set
by the programmer then it is automatically set to the registered default
value. But there's no good reason in this case to require that. I've
updated the code.
>
>
> Also, I read in gobject-tutorial that it is "absolutely necessary" to use
> gobject.type_register, yet you didn't. The program seems to work fine
> whether or not gobject.type_register is present. What are the
> ramifications of omitting this call?
In some cases gobject.type_register is called automatically by PyGTK.
This is done through the GObjectMeta metaclass. The logic it uses to
decide whether or not to call type_register automatically is easy to
follow in the source code:
http://svn.gnome.org/viewcvs/pygobject/trunk/gobject/__init__.py?view=markup
--
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/
[pygtk] Re: Re: Cannot subclass gtk.Widget
Gustavo J. A. M. Carneiro wrote:
> Another, more complex, example can be found here:
> http://telecom.inescporto.pt/~gjc/higcontainer/higcontainer.py
By studying the examples, I have learned a lot about subclassing. I have
two questions about this example. It seems desirable to me that it be
possible to call the subclass in the same manner used to call other PyGTK
classes. Thus, in the case of your example, the subclass would be
instantiated with
group = HIGContainer(title='Hello')
instead of
group = gobject.new(HIGContainer, title="Hello")
(In fact, I think it would be even more consistent to have
group = HIGContainer()
group.set_title("Hello")
)
When I make this change, I get the error message
'HIGContainer' object has no attribute '_HIGContainer__title'
The error vanishes when I drop the gobject.PARAM_CONSTRUCT, so evidently
gobject.new does something with __gproperties__ that does not happen
otherwise. What is the implication of dropping the gobject.PARAM_CONSTRUCT
flag and invoking the HIGContainer this way?
Also, I read in gobject-tutorial that it is "absolutely necessary" to use
gobject.type_register, yet you didn't. The program seems to work fine
whether or not gobject.type_register is present. What are the
ramifications of omitting this call?
--
Jeffrey Barish
___
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/
Re: [pygtk] Re: Re: Cannot subclass gtk.Widget
John Dennis wrote: > 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. It could be, but is not the case. do_*() methods *do* override default class handlers. Paul ___ 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/
Re: [pygtk] Re: Re: Cannot subclass gtk.Widget
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_ 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. -- John Dennis <[EMAIL PROTECTED]> ___ 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/
Re: [pygtk] Re: Re: Cannot subclass gtk.Widget
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_ 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. -- John Dennis <[EMAIL PROTECTED]> ___ 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/
[pygtk] Re: Re: Cannot subclass gtk.Widget
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. -- Jeffrey Barish ___ 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/
