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

Fri Jul 1 07:53:34 PDT 2011

Hi Benjamin,

> -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, 

Is multiple views here multiple views per page?
Was it ever supported?

> and we do not want to support a page without a view).

Why?
For example, in case of tabbed browsing there is no use to keep view with all caches attached to the page that is not in active tab.

> -simplify APIs to something minimal: QMobileWebView (the viewport) +
> QMobileWebPage (the view on the page) for mobile. QDesktopWebView as
> the only view for mobile.

Mobile/Desktop - sounds odd. Who knows, where will be mobile or desktop soon. Some phones are more powerful than other nettops ;)

> -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.

Wrong.
Some mobiles want drag and drop.
And this http://www.apple.com/magictrackpad/ and http://www.cirque.com/desktoptouchpad/productsandorders/easycat.aspx works fine with desktop and supports gestures.

In any case, looks great!

Sl

> -----Original Message-----
> From: webkit-qt-bounces at lists.webkit.org [mailto:webkit-qt-
> bounces at lists.webkit.org] On Behalf Of Poulain Benjamin (Nokia-MP-
> Qt/Oslo)
> Sent: Thursday, June 30, 2011 4:22 PM
> To: webkit-qt at lists.webkit.org
> Subject: [webkit-qt] Feedback needed: new design for WebKit 2
> 
> 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