[PyQt] design flaw in python khtml DOM bindings

[Jim Bublitz]

On Tuesday 14 October 2008 14:21, Luke Kenneth Casson Leighton wrote:
> folks, hi,
> thanks to some kind people on the kde-dev mailing list i'm posting
> here to describe an important design issue which makes the python
> khtml.DOM bindings completely unusable - for serious projects - unless
> it's fixed.
> the issue is that the wrapper objects aren't unique [don't return the
> same python object for a given DOM c++ object], due to the underlying
> c++ objects being typecast down to "Node*" (or Element*), and the use
> of the khtml.DOM.* "casting" functions being inadequate for the job.
> the issue is described in detail here:
>   http://lists.kde.org/?l=kde-devel&m=122398222122025&w=2
> the bugreport is here:
>   https://bugs.kde.org/show_bug.cgi?id=172740
> an example of the code which gets it _right_ - in webkit - is here:
>  http://github.com/lkcl/webkit/tree/16401.master/WebCore/bindings/gdom
> note the quite extensive html element wrapper factory, the extensive
> GDOMBindings.cpp which basically cover EVERY single object and i mean
> ALL of them, with a wrapper that ALWAYS goes via the Hashmap before
> returning the object.
> in this way, it is absolutely absolutely cast-iron-guaranteed that,
> even when you call KHTMLPart.document.getElementById("body_id") you
> WILL get a khtml.DOM.HTMLBodyElement back - NOT a khtml.DOM.Node.

It's a bug in twine - the PyKDE code generator. It should be generating code 
to cast factory-generated types to their actual type, and does for a variety 
of base classes (eg, QObject). DOM::Node is specified in the project file to 
have a %ConvertToSubClassCode block generated for it, but it appears twine is 
ignoring those for any base class declared in a namespace (works for 
subclasses in namespaces though). It'll work if dynamic_cast<> works for the 
class and hierarchy (not compiled with -fNO_RTTI or whatever the switch is 
that turns off RTTI)

Richard Dale's fix linked about should also work in this case if rolled into a 
proper %ConvertToSubClassCode block. However, in some cases like this, the 
KDE base class/derived classes don't have type info methods attached - 
twine's code should work generally if RTTI is enabled. But it wouldn't be 
maintained automatically, and you'd also have to add #includes for each 
subclass' header file, which twine should do automatically as well.

> i cannot express enough how much _not_ fixing this makes khtml
> completely unusable.

There were DOM applications written for PyKDE3, which also didn't do any 
promotion of factory-generated DOM::Node objects, and nobody indicated it was 
a problem there. Which is why it was never checked. 

Either way, it shouldn't be hard to fix. And then somebody (like people who 
need the feature and know how it should work) should write/contribute some 
test code to make sure it stays fixed.

Jim