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: [email protected] [mailto:webkit-qt- > [email protected]] On Behalf Of Poulain Benjamin (Nokia-MP- > Qt/Oslo) > Sent: Thursday, June 30, 2011 4:22 PM > To: [email protected] > 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 > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt _______________________________________________ webkit-qt mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
