On 06/30/2011 10:21 PM, Benjamin Poulain wrote:
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
Hi all,
I checked a bit the API proposal and I'm a bit "disoriented" by the
changes against previous APIs.
For example, in KDEwe baseour webkit integrationon theQWebPageclass,in
particularon the methods"setNetworkAccessManager"and
"acceptNavigationRequest".
How can the same be achieved in this new solution?
Probably (or not) out of contest, the same is true with the actual QML
WebView element. Am I missing something?
Cheers,
--
Andrea Diamantini, adjam
GPG Fingerprint: 57DE 8E32 7D1A 0E16 AA52 59D8 84F9 3ECD DBF9 730F
rekonq project
WEB: http://rekonq.kde.org
IRC: rekonq@freenode
_______________________________________________
webkit-qt mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
