Re: [PyQt] design flaw in python khtml DOM bindings
David Boddie wrote: I don't think it was a problem in PyKDE3. At least, I don't remember running into any issues with casting - not with the DOM classes anyway. My brother wrote some convenience wrappers around the KHTML DOM, so I think I would have heard something if it had been broken. Maybe it was broken, but just wasn't an issue. yeah - i don't believe anyone's tried something as ambitious as pyjamas using pykde3, before. yes i encountered the pykhtml convenience wrappers (they're great!) i'm doing some extension to it, to complete it into a more comprehensive wrapper set that i need for pyjamas, and i'm likely also to _re-port_ dom.py _back_ to the pyjamas-webkit port, because of the inconvenience of that stupid _stupid_ thing props that pygobject offers ARG :) ok - there already exists a wrapper to make that a dict, but for some reason it doesn't work. regarding your comment that there are no issues with casting: there are no issues with casting ... until you try to do comparisons against nodes, or you try to add extra variables to a node. e.g. like this: def onClick(event): print hello n = document().createTextNode(hello world) n.setId(hello_world_id) # or something that sets the attribute id=hello_world_id b = document().getElementsByClassName(body)[0] # khtmlpy syntax excuse me :) b.appendChild(n) n.listener_fn = onClick n.addEvent(onclick, n.listener_fn) # again, see khtmlpy does this work? errr no :) why doesn't it work? this is why: retrieve_n = document().getElementById(hello_world_id) assert(retrieve_n.innerHTML == n.innerHTML) # yep - this works. same node assert(retrieve_n == n) # WARK, WARK! oh dear - n != retrieve_n, even though it's the same c++ object. print n.listener_fn # yep - our original pointer has the listener_fn still in it function onClick... print retrieve_n.listener_fn # WARK, WARK! it's a different python wrapper... around the same c++ object! hope this clarifies. l. -- View this message in context: http://www.nabble.com/design-flaw-in-python-khtml-DOM-bindings-tp19982564p19992946.html Sent from the PyQt mailing list archive at Nabble.com. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] design flaw in python khtml DOM bindings
Jim Bublitz wrote: On Tuesday 14 October 2008 14:21, Luke Kenneth Casson Leighton wrote: 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. 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 ahhh. you are a star - thank you for letting me know that it's something that people are aware of, and is even, by the sounds of it, on its way to being fixed already. 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. yeah - it's only if you want to retrieve the nodes that you're adding, keep track of them (every single one created/added, in the case of the pyjamas API), identify them uniquely and make comparison-tests (node1 == node2) that you run into difficulties. 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. _great_. it'd just be really exciting to have several different desktop ports for the pyjamas API, to be able to demonstrate the point that it's truly platform- and browser- _and- widget-set- independent. so... yeah, i'd be more than happy to write some simple tests. it's really easy/straightforward to demonstrate: should take about 30 lines of code. l. -- View this message in context: http://www.nabble.com/design-flaw-in-python-khtml-DOM-bindings-tp19982564p19992772.html Sent from the PyQt mailing list archive at Nabble.com. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] design flaw in python khtml DOM bindings
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-develm=122398222122025w=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. i cannot express enough how much _not_ fixing this makes khtml completely unusable. i have got quite a long way already in porting pyjamas to khtml: http://github.com/lkcl/pyjamas-desktop/tree/master/pyjamas-khtml the port of pyjamas to khtml is in honour of khtml being the grand-daddy of webkit :) so, it'd be nice if it worked! but, being unable to do if node1 == node2 because there's no one-for-one mapping of c++ to python wrapper objects is a _complete_ show-stopper. l. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] design flaw in python khtml DOM bindings
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-develm=122398222122025w=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 listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] design flaw in python khtml DOM bindings
On Tue Oct 14 23:34:29 BST 2008, Jim Bublitz wrote: On Tuesday 14 October 2008 14:21, Luke Kenneth Casson Leighton wrote: 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. I don't think it was a problem in PyKDE3. At least, I don't remember running into any issues with casting - not with the DOM classes anyway. My brother wrote some convenience wrappers around the KHTML DOM, so I think I would have heard something if it had been broken. Maybe it was broken, but just wasn't an issue. David ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
