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

[Andrea Diamantini]

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
> webkit-qt at lists.webkit.org
> 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 at freenode

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-qt/attachments/20110703/36333b4c/attachment.html>