On Mon, 7 Jun 2010 00:02:06 +0000, Luke Kenneth Casson Leighton <[email protected]> wrote: > henning schroeder created an experimental port of pyjamas desktop to > pyqt4 some months ago: i resurrected it and placed it into the latest > git on http://sf.net/projects/pyjamas. i'm pleased to be able to say > that, thanks to the efforts made so far by the pyqt4 team, the pyqt4 > pypjd experimental port is surprisingly functional. > > ... however for the pyjd pyqt4 port to work 100%, absolutely 100% and > i mean absolute total and full coverage of absolutely every single > feature present in webkit is required to be re-presented through the > python bindings. without exception and without fail, _everything_ is > required, on a par with the javascript bindings - concept-for-concept, > function-for-function, property-for-property. i realise that that > means some 450 element types, around 4,000 functions and some 30,000 > properties, but the MS IE team have done it (over 10-15 years ago) > with their COM interfaces to MSHTML and MSXML, and glib/gobject > bindings to webkit-gtk have been around for going on 18 months > (providing some 300 element types, around 2000-3000 functions and some > 20,000 properties). > > now, it turns out that some of the features which are missing from > QWebElement can be "faked" by executing javascript code-fragments, and > it is to the pyqt4 qtwebkit designers' credit to have access to this > feature: it is an excellent design decision. so, for example, events > can be handled by creating a snippet of javascript code that happens > to result in a callback to a python function. an element's nodeType > can be accessed by executing the codefragment "this.nodeType", which > results in a QObject being returned that python typecasts back to an > int. > > but when it comes to accessing a table's "row" property, everything > falls apart. perhaps this is simply a bug, because the table being > accessed is empty, and has no rows. perhaps, instead of returning a > QWebElementCollection which happens to be empty, an empty string is > returned: i don't know. > > all i know is that QWebElement is far from complete, and is really > incredibly awkward to use. it's a long long way away from looking > like the W3C DOM functions and properties it's supposed to present > (cloneNode has been renamed to clone, and doesn't take the necessary > boolean argument for example). > > that makes it especially challenging for anyone wishing to learn how > to use it, because you cannot rely on knowledge of javascript or W3C > specifications in order to "guess" with a high degree of accuracy what > the API might be: you have to go look up riverbankcomputing qt4 web > site documentation and do a mental conceptual translation. > > so i just wanted people to know that whilst i'm pleased to say that, > thanks to the fantastic efforts made so far by the QtWebKit team, at > least one pyjamas desktop example works (helloworld) including being > able to click a button, change the text of the DOM, and fire up a > dialog / alert box, the pyqt4-qtwebkit porting exercise shows that > there is still quite a lot left to be done. > > so i wanted to know what the developers' reactions and intentions are > wrt. QtWebKit. is the intent that QtWebKit be a proper and full peer > to javascript bindings, or is the intent that it have a... limited > (and ultimately unsatisfactory) subset of W3C DOM functionality?
QtWebKit, not PyQt, provides the bridge between C++ and JavaScript. PyQt integrates Python with Qt's meta-object system which gives you the bridge between Python and JavaScript for free. If the problem is that you can do something in C++ that you can't do in Python then it's a PyQt bug - but you need to be a bit more specific about what the problem is. Otherwise you should be asking Nokia for changes in QtWebKit. Phil _______________________________________________ PyQt mailing list [email protected] http://www.riverbankcomputing.com/mailman/listinfo/pyqt
