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 _______________________________________________ PyQt mailing list PyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
