[webkit-qt] Feedback needed: new design for WebKit 2

[Benjamin Poulain]

Hi all,

Andreas and I have worked a couple of days on a ways to clean the 
current mess of the WebKit 2 API. We would like some feedback before 
going forward and upstreaming some of that :)

I has become visible that the current design of the UI layer of WebKit 2 
is not maintainable. The code is becoming really messy, and it is hard 
to know where to add new features.

Some of problems we have are:
-the split QWKPage <-> QGraphicsWKView comes from the design of our 
WebKit 1 APIs, and is just adding complexity (we do not want to support 
multiple views, and we do not want to support a page without a view).
-There is not clear layering, nor a clear split of responsibilities 
between the classes. This is to the point where QGraphicsWKView call 
directly methods of the page proxy through the private object of 
QWKPage, the TiledDrawingArea is fully aware of the view implementation, 
the QWKPage is aware of the GraphicsView.
-QGraphicsWKView is a mashup of many things (2 BackingStoreType, 2 
rendering model, etc)
-We expose more APIs than we want to support at the moment (QWKHistory, 
QWKPreference, etc).


We have been playing with the code, trying to break it in less 
monstruous parts.
This is available here: 
https://github.com/kling/webkit/tree/master/Source/WebKit2/UIProcess/API/qt

The goals:
-clarify the responsibilities of each class
-the view should not be aware of WebKit internals, QWebPageProxy is our 
door to the internal APIs.
-simplify APIs to something minimal: QMobileWebView (the viewport) + 
QMobileWebPage (the view on the page) for mobile. QDesktopWebView as the 
only view for mobile.
-do not mix the needs of Desktop and needs of Mobile. For example, drag 
and drop should not clutter mobile classes, and gesture support should 
not clutter the desktop classes.
Same for the drawing area implementation. We do not support two 
implementation in one view, the mobile only support tiling, the desktop 
only support the regular drawing area. Ideally, the view should not even 
care about the implementation of the drawing area.
-BUT: do not have duplicated code between desktop and mobile.


When events come in from Qt to the API, the path is:
-QMobileWebPage/QDesktopWebPage -> QWebPageProxy -> WebPageProxy
The problem of the two drawing area is solved by having subclass of 
QWebPageProxy for mobile and desktop.

When events come up from the WebKit internals to Qt, the path is:
-QWebPageProxy -> ViewInterface -> QDesktopWebPage / 
(QMobileWebView|QMobileWebPage).
The view interface is an interface abstracting the fact that the mobile 
view is not one but two views. It is also a way to not clutter the 
subclasses of QWebPageProxy by making them the delegate of every 
function of the PageClient.


Examples in practice:

1) The client initiate drag and drop (WebProcess->UIProcess transaction):
-The page proxy get the call from the web process:
https://github.com/kling/webkit/blob/master/Source/WebKit2/UIProcess/API/qt/qwebpageproxy.cpp#L814
-The types are converted in Qt types by QWebPageProxy
-The method startDrag() is called on the view interface
-The mobile case does not handle drag and drop so its view interface can 
just ignore the call: 
https://github.com/kling/webkit/blob/master/Source/WebKit2/UIProcess/API/qt/mobileviewinterface.cpp#L63
-The desktop case support drag, so its interface implement the function:
https://github.com/kling/webkit/blob/master/Source/WebKit2/UIProcess/API/qt/qdesktopwebview.cpp#L63


2) The view needs to re-paint a region (UIProcess->WebProcess):
-The view just forward the event to QWebPageProxy 
https://github.com/kling/webkit/blob/master/Source/WebKit2/UIProcess/API/qt/qdesktopwebview.cpp#L115
-The page proxy execute the common code and delegate the actual 
rendering to its subclasses: 
https://github.com/kling/webkit/blob/master/Source/WebKit2/UIProcess/API/qt/qwebpageproxy.cpp#L428
-The subclass does the painting the way it should be done with whatever 
drawing area it uses: 
https://github.com/kling/webkit/blob/master/Source/WebKit2/UIProcess/API/qt/qdesktopwebpageproxy.cpp#L61


This split is working rather well at the moment so it would be nice to 
get some input.
-Do you forsee any problem with this?
-Do you have suggestion to improve this?
-Do you think QWebPageProxy has too many responsibilities? Any idea how 
to improve that?
-Do you have a better solution altogether to the problem?

Unless the whole thing fall appart, I would like this to be upstreamed 
as soon as possible in order to start implementing the mobile view, and 
start the switch to Qt 5 for the rendering.

cheers,
Benjamin