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

[lkcl]

David Boddie wrote:
> 
>> 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.
> 
_great_.  whew.  :)



> 
>> 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.
> 

yep.  at runtime.  thus ensuring, with the help of the code in
GDOMBindings.cpp and GDOMHTMLElementWrapperFactory.cpp,
a one-to-one and onto mapping between c++ objects and
glib objects, and thus helping python and other bindings do
likewise.

just like python-kde _doesn't_ do at the moment (thanks to
paul for the info about the bug in kde "twine")



> In Qt, whoever writes the code to bind WebKit's DOM to Qt's object model
> will do the same thing.
> 

we _hope_ :)



> Right now, there are no Qt-style bindings to the WebKit DOM
> implementation,
> 

i know :)  been keeping an eye on things for a couple of months.



> 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.
> 

i was surprised to find that it's pretty similar.  KJS got renamed
last month (to JKS or something).  but only renamed.
SVG Canvas is missing of course.  but, there's surprisingly
still very big similarities.  it's not like you _need_ to change
things that drastically.



> 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.
> 

by the time it gets to python, whatever mechanism is used is
immaterial - it will either all be the same or will be possible to
_make_ it all look the same.

see later on... i don't believe it's necessary [to have a qt-style impl.]



>> 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 -
>> [...]
>> 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.
> 

yes - that's what i would imagine would be the case.  i've documented
(with a post to webkit-dev and also a webkit bugreport:
https://bugs.webkit.org/show_bug.cgi?id=20632 )
that with a tiiiny bit of work on tweaking the interaction between the
port and the webkit library, you (as in, "the person doing the qt dom
bindings", or "the person editing the webkit qt port") will be able to
get a WebCore::Frame c++ object "into the clutches" of the webkit-glib
bindings _without_ having any impact - whatsoever - on the rest of
the code.

once the webkit glib bindings have the WebCore::Frame, access to
the entire set of 1500+ webkit-glib DOM functions and the 300+
webkit-glib DOM objects is possible.

then, you (a developer who is using QWebKit and/or python-qwebkit)
would be able to set up a QWebKit window, call a single function and
"extract" that webkit-glib wrapper (GDomFrame) and, without a single
bit of disruption to their existing pre-written app, with zero changes
to their API, be able to gain access to and control over the DOM model.

it might feel a bit odd, if they were directly using the c code, but if
things like webkit-mm are used to auto-generate c++ bindings,
or codegen.py are used to auto-generate python bindings, that
"oddness" goes away.

and, particularly neatly, as a developer, if you want to do _just_
a python-webkitqt app, or _just_ a python-webkitgtk app, without
doing any DOM bindings, you just... don't install the
python-webkit-glib-dom-bindings python module.

and, if you _do_ want to do DOM bindings manipulation, then
you would be able to use the _same_ library, expect the _same_
API, irrespective of whether your app was a python-qt/webkit one
or a python-gtk/webkit one.

which would be _really_ neat.

the only people i really truly anticipate will be using the c-based
webkit-glib bindings directly would be those people writing test
cases, in webkit.

regarding making webkit-qt bindings - i.e. auto-generating code
that uses Qt4 and QObject: i really can't see any clear advantage
using QObject/qt over Gobject/glib.

the reasoning is this: there isn't a way, in any of the webkit "ports"
as they are called, to embed widgets into the "viewing" area
(unless it's done via the NPAPI e.g. like a flash plugin, and then
you're entirely free to embed e.g. gtk into webkit-qt, or wxWidgets
into webkit-gtk, but that's a different story).

to explain: the webkit "viewing area" is effectively untoucheable
by other widgets.  you can't place a QButton into the middle of
a QWebkit-rendered "view" of an HTML page (unfortunately).  you
can't place a GTK.Label into the middle of a WebKitGTK-rendered
"view".

the webkit "viewing area" is effectively like the drawing of a bmp /
pixmap.  there's no level of interaction (except mouse and keyboard
events).

consequently, the manner in which the DOM model - the "viewing area" -
is manipulated matters a lot less than it would if it were possible to
drop widgets into the "viewing area".




> 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? ;-)
> 

:)  i'm thinking ahead.  to the time when some poor bugger has to
actually do this work.  it might be me - if someone commissions me
to do it.  it might be someone else, in which case i hope that they
will find these discussions useful.

l.

-- 
View this message in context: http://www.nabble.com/python-bindings-to-qwebkit---who%27s-responsible-for-doing-this-work-%28anyone-%29-tp19982574p19994271.html
Sent from the PyQt mailing list archive at Nabble.com.