[webkit-qt] PageClient Refactor and a new setView() use case
simon.hausmann at nokia.com
Fri Apr 30 00:49:50 PDT 2010
On Thursday 29 April 2010 ext Jesus Sanchez-Palencia, wrote:
> Hello there, QtWebKit hackers!
> I've been working on a PageClient refactor for QtWebKit.
> The main motivation for this came from the fact that nowadays our API has
> QWebPage::setView(QWidget*) but has nothing to deal with QGraphicsWidgets.
> People were starting to do QWebPage::setView(QGraphicsView*), but this was
> leading us to bugs since the API is not ready to deal with the
> QGraphicsView family.
> So, I've prepared 2 patches for this:
> - one refactor for the QWidget's PageClient
> (https://bugs.webkit.org/show_bug.cgi?id=37858), which is already landed;
> - and a more complex one for adding a QGraphicsWidget PageClient and a
> This last one, basically, moved code from QGraphicsWebViewPrivate
> (including Tiling and AC specific stuff) to a "real" PageClient and
> removed the inheritance from it (this private class _was_, in fact, the
> PageClient of the QGraphicsWebView).
> I'd like some feedback from you in order to understand what do you think
> about this patch and if you consider this new setView API a valid use case
> or not. I'm aware that Plasma (from KDE) is using it and that it might be
> useful for the QML folks.
> Also, should this go into QtWebKit 2.0 or should we just leave it for
> QtWebKit 2.1?
> I already have the r+ for the patch, but we agreed to wait for this
> discussion before deciding when to land it.
Adding support for using QWebPage with an arbitrary QGraphicsWidget as view is
consistent with our existing API where you can use any QWidget with QWebPage.
It is also tempting to offer this because we think it may solve some problems
in KDE and maybe make life easier for QML.
With the QWidget as view, it is the programmer's responsibility to carefully
deliver events to QWebPage, from user input to painting. The provided view is
used as a container to place plugins in, used as a parent for popups and it
will be the paint device used for painting.
The primary use-case I can think of here is the ability to use a QGLWidget as
view (if for some reason QGraphicsView is not a choice).
From the perspective of the implementation the Qt port of WebKit there are
many advantages to moving to an entirely QGraphicsView based stack. Certain
new features currently only work with QGraphicsWebView, such as WebGL or
accelerated compositing. If we want to continue down that road, then the use-
case of plugging an arbitrary QWidget as a view to QWebPage becomes difficult to
support. Essentially I think we have to drop it or we continue to support both
code paths in WebKit.
_If_ we have to drop the any-QWidget-with-QWebPage option from the API, then
what exactly are the advantages of providing a QGraphicsWidget replacement?
I mean, with QWebPage::setView(QGraphicsWidget*); the provided QGraphicsWidget
becomes entirely owned by QtWebKit. We add child items (for AC and tiled
backing store), we place plugins, etc. What's left for the programmer? The
boring task of passing events.
How are we making the life of programmers easier that way? What exactly are we
making possible that is so much harder if all we provide is QGraphicsWebView
and embedding requires aggregation as a child item in the application?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: This is a digitally signed message part.
More information about the webkit-qt