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

[Benjamin Poulain]

On 07/01/2011 11:46 AM, ext Kenneth Rohde Christiansen wrote:
>> 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.

By internal I mean all the stuff in namespace WebCore, WebKit, WTF, etc.

I think there is no problems if classes like ViewportAttributes go to 
the upper layer. I am only concerned of the view knowing everything 
about the internals like QGraphicsWKView today.

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

The only thing exposed will be QML yes, the names are internal.
Let's not bikeshed too much on this before we need to expose the APIs... 
We already had quite some of that yesterday on IRC :)

The one popular suggestion I have seen yesterday is to rename QMobileXXX 
to QTouchXXX

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

Nope it is not.

The implementation of the page client still exist. I think mixing 
PageClient and the calls to the views would be even more confusing than 
what is on trunk at the moment.

cheers,
Benjamin