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? tia, l. _______________________________________________ PyQt mailing list [email protected] http://www.riverbankcomputing.com/mailman/listinfo/pyqt
