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

[Luke Kenneth Casson Leighton]

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.