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

Fri Jul 1 02:46:08 PDT 2011

Hi there,

On Thu, Jun 30, 2011 at 10:21 PM, Benjamin Poulain
<benjamin.poulain at nokia.com> 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 :)

Great stuff :-)

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

I guess this depends on what you call internals. The process
separation already limits this in many ways. So what you are trying is
to get rid of IntRect etc? Does it makes sense to wrap let's say
viewport meta in our own class just to accomplish this? Not that I am
against your suggestion, I just wanted to know if there is a real
advantage in this? If WebCore/WebKit2 api changes,
 we will probably have to change our classes as well.

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

These names confuse me. The C++ api is for people knowing what they
are doing, everyone else should just be using our [future] QML view.

What about QMobileWebViewport and QWebPageContents or similar?

Would someone (C++ api user) ever need to access the api of the
QWebPageContents directly? Does it makes sence? or is it an
implementation detail?

Also I don't like the name "mobile". "mobile" and "desktop" are
converging - just look at Safari on Mac OS X Lion. It is more a
differentiation of the interaction model. One based primarily on
touch, the other primarily based on mouse + keyboard.

What about QWebViewport and QTraditionalWebView ?

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

On the other hand, (look at the Sencha blog for instance) people are
requesting native drag and drop support for mobile. But yes, at that
point it could be added. Also why would people not want gesture
support in desktop browsers? Many laptops have gesture pads today or
will have.

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

fine.

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

ViewInterface seems pretty much what was the idea of PageClient,
except the part where you are "filtering" what we are not currently
needing. Why not just call it QtPageClient or so to not make this more
confusing than needs to be.

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

-- 
Kenneth Rohde Christiansen
Senior Engineer
Application and Service Frameworks, Nokia Danmark A/S
Phone  +45 4093 0598 / E-mail kenneth.christiansen at gmail.com

http://codeposts.blogspot.com ﹆﹆﹆