[webkit-qt] PageClient Refactor and a new setView() use case

[Simon Hausmann]

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
> QWebPage::setView(QGraphicsWidget*)
> (https://bugs.webkit.org/show_bug.cgi?id=37866).
> 
> 
> 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?


Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.webkit.org/pipermail/webkit-qt/attachments/20100430/9b5d39dc/attachment.bin>