[PyKDE] KXMLGUIFactory.container()

Phil Thompson phil at river-bank.demon.co.uk
Mon Apr 14 10:22:00 BST 2003


On Monday 14 April 2003 5:12 am, Jim Bublitz wrote:
> On 14-Apr-03 Gordon Tyler wrote:
> > On April 13, 2003 08:19 pm, Jim Bublitz wrote:
> >> wasn't aware of any problems in this area. There are a only a
> >> few cases where KMainWindow wouldn't be the "main" class -
> >> using KParts and (maybe) KSystemTray stuff. The other case
> >> would be with some kind of Python plugin (as in panel applets
> >> discussed recently), where Python doesn't do the KApplication
> >> or KMainWindow.
> >
> > By "main" class, I think Phil just meant "an important class in
> > the module". So KMainWindow is an important class in kdeui.
> > KApplication would be an important class in kdecore. They're
> > just used as a place to locate the subclass conversion table.
>
> Right - I misread that.
>
> > Phil, does this table need to have every PyKDE class listed?
>
> In the particular case you're inquiring about, your patch covers
> all of the possibilities. Ownership (between Python and C++)
> shouldn't be a problem in this case because the objects returned
> are already owned by a C++ instance like KMainWindow, which will
> also take care of deallocating the object.
>
> If I recall correctly (maybe Phil will know), this came up last
> year in a discussion that resulted from some changes Phil made for
> another developer. I decided at that time not to include
> ConvertToSubclassCode in PyKDE because I wasn't aware of any place
> it was needed except for KParts, which PyKDE already handled
> differently. (the methodology was different too, I believe, and
> would have involved a *lot* more work at that time).
>
> If I understand this correctly, it solves the problem of methods
> that return a QWidget or QObject (eg QObject::child,
> QWidget::childAt), and allows access to the actual QWidget or
> QObject subclass (eg a child might be QListBox or KEdit) - roughly
> the equivalent of casting the returned value to the subclass type
> in C++. If that's the case, I probably should include
> ConvertToSubclassCode in PyKDE, at least for QObject/QWidget
> subclasses.
>
> Have I got that right, or am I still confused?

That's correct. It should be provided for any type that provides rtti. In PyQt 
this is QObject and QEvent. (I should also do QCanvasItem, but I seem to have 
missed that.)

> Also (Phil), does the actual %ConvertToSubclassCode block need to
> reside inside a class, or can it be in global space? I noticed the
> way you handled it in qobject.sip, which would get the bulk of the
> actual code outside of a class, so I'm just wondering about the
> %Convert... block itself.

It must be inside a class because SIP needs to know the base class (eg. 
QObject or QEvent). So my previous response about the "main" class was wrong 
(I was relying on memory which is probably not a good thing to do at my age).

If you are defining %ConvertToSubClassCode for the base class then it must 
appear in that base class.

If you are defining it for a number of derived classes where the base class is 
in another module then it just needs to be in one of those derived classes. 
It doesn't matter which one. If you wanted to you could put one in each of 
those derived classes containing an entry for that class only - but that 
would be less efficient.

Phil




More information about the PyQt mailing list