[webkit-qt] QtQuick QML API for WebKit1
simon.hausmann at digia.com
Tue Mar 12 02:44:26 PDT 2013
On Wednesday, February 13, 2013 04:47:55 PM Alberto Mardegan wrote:
> Hi all!
> I plan to spend some time on building a QtQuick (Qt5) plugin for WebKit1.
> There are several reasons why I want to do this, the main ones being the
> possibility of playing with the cookie jar and having direct access to the
> It should also make sense for people who need just a quick web renderer
> and don't need the split-process design (for instance, for a help
> application rendering local content).
> I'm basically writing this e-mail FYI, and of course to collect early
> feedback (let me know if you see any sense in this effort, or whether
> you welcome it).
I'm going to use the opportunity to give some feedback :)
You may observe a trend out there in the way WebKit is used nowadays: The core
engine has a tendency to run on a separate thread (iOS) or a separate process
(Safari, Chromium), even when embedded in applications.
The core engine is running in one big fat event loop that is slowly breaking
apart. Efforts are underway to move HTML parsing into a separate thread, the
networking is usually already on a different thread (or even process) and the
web developers are starting to move heavier scripts into the more widely
loop that is very easy to stall by simply not returning to it quickly enough.
The fact that QtQuick2 tries to move the GL rendering into a separate thread
also helps here, but it's not a catch-all solution, especially not if we want
to continue to make it easy for developers to write things in a synchronous
way in the main event loop and we do the other heavy processing elsewhere.
(i.e. us not getting into the way of the application developer)
It is simply in the nature of the web as a platform that in an onclick handler
you can do whatever you want however long you want and nobody can stop you.
That API isn't going to go away anytime soon and I don't think that it the
behaviour can be changed without breaking half of the web out there :)
However at the same time the users out there have higher expectations than
ever towards the speed of computers, and that mostly refers to perceived
That I believe is the primary motivation towards the established model of
separating WebKit into a thread or process. It is a clear trend within the
project and its users.
There are only two ways of using WebKit that way, WebKit2 or Chromium. We have
chosen the former, along with the other communities (our friends from EFL and
Gtk+ for example).
For compatibility we do have to keep the single-threaded WebKit code paths
around (aka QWebPage/QWebView in Qt), but with my Qt project module maintainer
hat on I would welcome efforts to _reduce_ the maintenance of that instead of
adding to it. We should streamline our efforts and work on the same things.
Consequently with that information at hand I'm not in favour of having a
QtQuick2 integration that is based on the single-threaded WebKit in the
upstream source tree. We need some better arguments on the table :)
As mentioned in earlier mails, I would much rather welcome efforts to make the
use-cases work that you're interested in in the world of WebKit2. There's
nothing inherent in a process separation that makes things like DOM access
impossible. It just works slightly differently. For example by writing the code
loop. Extract the information you need and pass it back to the application.
I recently learned that the KDAB folks apparently have had success with doing
simple QObject bindings across process boundaries. With reasonable contraints
that are documented (properties would be value cached, so don't expose heavy
content for example) that might be a workable alternative to make hybrid use-
> Though I didn't dig very deep so far, my understanding is that I cannot
> implement this as a completely separate module, but I'm afraid it will
> have to be part of the webkit source tree (and share a lot of code with
> the QtWebkitWidgets module). So suggestions on how to handle this are
> very welcome.
> I didn't write any code yet, and I probably won't start before 1-2
> weeks, but if anyone is interesting in helping me out please drop me a
> line. :-)
More information about the webkit-qt