[PyQt] python bindings to qwebkit - who's responsible for doing this work (anyone?)

[David Boddie]

On Tuesday 14 October 2008, Luke Kenneth Casson Leighton wrote:

> it's _this_ why i'm looking to contact the people who are doing the
> work on QWebKit, to find out what the plans are, for doing python
> bindings, and to advise you - whomever you might be - to watch out for
> two things:
> 1) not to make the same design mistake
> 2) to consider ways in which drastic amounts of development time can be
> saved

You may be jumping the gun here. You'll see what I mean a bit further down.

> ... allow me to explain :)  issue 1, first.
>
> there's something very, very important that gobject can do, and i am
> unsure that it is appropriate to use e.g. QObject to do the same
> thing, or even if Qt4 is capable of doing what gobject can provide
> (which it could very well do, but i don't know how), and it's this:
> gobject can do "base classing".  object inheritance trees, and,
> absolutely absolutely critically, run-time typecasting.

Yes, QObject provides this feature in C++ - well, there are various classes
involved, but that's not important right now.

> even more importantly than that, python-gobject can "pick up" on the
> gobject "type" and will return the correct python object.  the key is
> here, in create_gdom_object(), line 284, of GDOMBindings.cpp:
> http://github.com/lkcl/webkit/tree/16401.master/WebCore/bindings/gdom/GDOMB
>inding.cpp#L294 the critical line is this:
>    gpointer res = g_object_new(dob->getGobjType(), NULL);
> that getGobjType() function is a pure virtual function, in the glib
> bindings c++ object (which represents the webkit DOM object).  the
> auto-generator (Gobject.pm) creates each and every one of the 300
> class instances where getGobjType() is declared, and so they return a
> GDOM_GOBJECT_TYPE_NODE, GDOM_GOBJECT_TYPE_ELEMENT,
> GDOM_GOBJECT_TYPE_HTML_BODY_ELEMENT etc. etc. etc.

Right, so the gobject bindings do the work of finding out what the type is.
In Qt, whoever writes the code to bind WebKit's DOM to Qt's object model
will do the same thing.

Right now, there are no Qt-style bindings to the WebKit DOM implementation,
only classes for Web pages, frames, and other browser-related features:

  http://doc.trolltech.com/4.4/qtwebkit.html

When they become available, the way that the DOM element types are handled
will depend on the binding implementation.

> like i mentioned in my previous post, regarding khtml.DOM, i cannot
> express enough how absolutely vital it is that this issue is done
> correctly.  as a "workaround", khtml.DOM offers "typecasting"
> functions - in python - and the use of these functions is a complete
> nightmare (for reasons explained in the kde-devel post)

As you say in your other message, it just seems that the downcasting is
incomplete. There may be other issues with the implementation, but I
estimate that I haven't looked at the source for the KHTML bindings in
over three years, so it could all be completely different now, anyway.

[...]

> if you utilise the glib bindings to webkit to provide python-qwebkit
> with bindings to webkit's DOM model, my guess is that it would take
> about... oooo.... eight hours, absolute maximum.

You might also run into problems with glib/non-glib builds of Qt.
I don't know if it would really be a problem, though.

As mentioned earlier, I would imagine that DOM bindings for PyQt will
appear when they are provided in Qt, and will only have the same scope
as those bindings. This might be a showstopper for you if you were
expecting to use a Qt-style implementation to access the DOM.

[...]

> so, my _recommendation_ would be to not turn noses up at gobject.h and
> glib.h just because they've got the letter "g" in front of them -
> you're _exceedingly unlikely to want to wrap each and every single
> object in a DOM model with a full-blown QWidget - that's wildly
> inappropriate.  you're not going to need to pull in gtk2 libraries.
> vast amounts of time and effort are saved by pulling in _just_
> libglib.

If it can live in parallel with whatever implementation shows up in Qt
then I'm sure everyone will be happy.

At the moment, though, you seem to be the most interested in having these
features, so why are you using the word "you" so much when talking about
implementing them? ;-)

David