[PyQt] design flaw in python khtml DOM bindings

[Jim Bublitz]

On Sunday 26 October 2008 12:48, lkcl wrote:
> jim, hi,
>
> https://bugs.kde.org/show_bug.cgi?id=172740
>
> the maintainers of the khtmlpart have agreed to add an enum to uniquely
> identify every single object derived from Node, which should help.
>
> are you _sure_ it's to do with twine - twine is going to have to be
> _seriously_ sophisticated, to understand the inter-relationships between
> Node* derived classes, such that even when you do
> getElementById("something") from the python bindings, an e.g.
> DOM.HTMLElementBody class or a DOM.HTMLTableElement (or whatever) is
> returned, not a DOM.Node object, and also to be able to maintain a
> one-to-one and onto mapping between c++ and python objects.
>
> i'll be dead-impressed if it does.  _really_ impressed.

Don't be impressed - it's pretty simple. Twine collects all of the inheritance 
information as it parses the h files. The project file specifies which base 
classes to generate sip %ConvertToSubClassCode blocks for and then generates 
that code from the inheritance hierarchy. That's the code that does object 
promotion, say for a factory which always returns a QObject no matter what 
QObject descendant it creates. (twine could just generate 
%ConvertToSubClassCode blocks for any inheritance relationships, but for some 
reason I don't recall - dating to twine's predecessor presip, which did the 
same stuff -  it isn't desireable to do that for every possibility)

In terms of twine, the enum won't make any difference unless twine is modified 
to use it - twine generates PyKDE code that uses dynamic_cast<> to work back 
up the inheritance tree to find the highest level class an object is derived 
from (because, as in the current case with DOM::Node, not all KDE objects can 
be interrogated for inheritance info).  If RTTI is turned off when compiling, 
then dynamic_cast won't work though.

The bug in twine is that no hierarchy whose base class is declared in a 
namespace (like DOM::Node) is handled correctly. Non-namespaced base classes 
(like QObject) work fine. It's some bug in the way fully-qualified names are 
handled - I haven't looked into it because Simon is maintaining twine now, 
and it isn't obvious just from looking at the code.

It's all done in twine/plugins/subclass.py.

JIm