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
_______________________________________________
webkit-qt mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
