[PyKDE] KXMLGUIFactory.container()

[Jim Bublitz]

On 14-Apr-03 Phil Thompson wrote:
> 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.

OK - at the time this originally came up, my "automation" wouldn't
handle this at all, so I'd would have had to redo it manually for
each release. I think I'm accumulating all the necessary info now,
and (like sip) I'm doing a module-at-a-time rather than a
file-at-a-time, so I should be able to handle this easily now and
add it to a single derived class. That would be the most common
case for PyKDE: the QObject/QWidget descendants.

I have a another bugfix release coming in the next week or two, so
I'll include Gordon's patch with that. I'll pick up the rest down
the road - hopefully for 3.6.

Questions:

If I have two hierarchies:

QObject -> QWidget -> KEdit, etc.  
KAction -> KStdAction

then I'd need a %ConvertToSubclassCode block somewhere in the
QWidget hierarchy, and a separate %Convert... block in the KAction
hierarchy, even though both are in the kdeui module, right? Or can
I mix and match hierarchies in a single %Convert... structure? (I
assume the former, since QObject and QEvent are both in qt and have
separate entries).

Also, the maps and sipMapStringToClass are local to the module? In
other words, I shouldn't be appending the kdeui map to the qt map,
right?

Lastly, is sipMapCppToSelfSubclass related to this? For example, in
%MappedType QObjectList, is that necessary to preserve the type
info for elements of the list?

Note to me: Remember to fix the sipName_* entries for 3.6.


Jim