[webkit-qt] New WebKit2 architecture.

[Kenneth Rohde Christiansen]

Hi there,

I tried to implement the viewport meta handling for WebKit2 in trunk
and I'm not liking the new architecture :-( Let me explain to you how
I am seeing the current WebKit2 architecture and what I think can be
done differently.

Current WebKit2 architecture (Very raw description)

Process side ---
WebPage:
- Represents WebCore::Page plus aggregates FrameLoaderClient,
WebChromeClient, WebEditorClient, etc

UI side ---
WebPageProxy:
- Proxy for interfacing with the WebCore::Page and the various clients.
- Basically api for talking to the page, plus change notifications
from the page and clients
- Handles process state, restart, page groups internally etc
- It also does a bit of ipc argument decoding for some methods.

- It splits "notifications"/callbacks out into ContextMenuClient,
FindClient, ResourceLoadClient, FormClient, PolicyClient,
LoaderClient, UIClient and PageClient


QtWebPageProxy:
- Aggregates all the clients that WebPageProxy splits into
- Implements what is shared for Qt

- It splits notifications out into ViewInterface which splits into
TouchViewInterface and DesktopViewInterface


So the current (new) architecture is done to avoid duplicating code
and possible because it is believe that the Apple's made split doesn't
fit us.


I think this is a bit sad, because it seems that we are saying that
the current WebKit 2 architecture doesn't work for us, so instead we
implement another layer on top, forcing us to go thru many layers to
do even basic stuff.


So the UIClient and PageClient are supposed to be what should be
implemented by a given view. The split between those are (at least
that is what I believe) due to Apple exposing part of the view
implementation as an API so that they can customize it for Safari,
iTunes, their email client etc. We don't need that (at least for now).

It should be possible to implement all other clients for use by both
views (or if not, we could modify WebPageProxy and the clients to make
this possible).


I would suggest that we create a class like QtWebPageClient or maybe
QtWebViewClient which
- inherits from PageClient
- adds the UIClient
- implement view related things which can be shared between both of our views
- add things to PageClient that are currently missing and that we need
- adds empty methods for what is only used by one of our views.

Some of the other clients will also differ from the views, such as
FindClient. Some of these might be browser/app related and should be
kept separates. Others we might want to add default implementation
for, such as the ContextMenuClient, but that just means taht we
implement two separate classes and attach them to the view via the
current C API.


Then QWebTouchViewPrivate can inherit from the QtWebViewClient.

Cheers,
Kenneth

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