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 ﹆﹆﹆ _______________________________________________ webkit-qt mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
