[PyQt] design flaw in python khtml DOM bindings

[lkcl]

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.

l.


Jim Bublitz wrote:
> 
>> 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 
> [...]
> 
> 

-- 
View this message in context: http://www.nabble.com/design-flaw-in-python-khtml-DOM-bindings-tp19982564p20177253.html
Sent from the PyQt mailing list archive at Nabble.com.