[PyQt] pyjamas desktop port now using pyqt4: bugs and limitations of PyQt4.QtWebKit encountered

[Phil Thompson]

On Mon, 7 Jun 2010 00:02:06 +0000, Luke Kenneth Casson Leighton
<lkcl at lkcl.net> 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