Hi all, I drew a diagram to show the WK objects as exposed by Apple's C APIs, and how the object hierarchies stack up for the Qt port of WebKit2. As I was more interested in the "core" classes, WebProcess configurability and the Injected Bundle, I have intentionally omitted the Qt C++ wrappers around the WK C APIs, and the QML interfaces.
https://docs.google.com/drawings/d/1DWDehptk5Vyxkm-90oAiZTZy_4Y1UHsGVqF7vpGxZpc/edit?hl=en_US I am sending this out in case it helps grease the communication about "what features do we expose and how" discussion. Additionally, please let me know of any errors and I will fix them. OK? :) Here are some of my observations based on the figure: 1. WKViews can be configured to three separate complexity levels: lite, medium, and advanced. If you follow the left to right vector in the diagram, these 3 types of application instances are shown. A "lite" or DocumentViewer use case is a simple application like Help viewer, Medium (DocumentBrowser) is perhaps like a Mail application that requires more memory, and a "power user" (PrimaryBrowser) might be a full browser (duh!). IIUC, Apple's WebKit1 API has always exposed this functionality to the API user. *We should consider passing through this functionality to the QML*. Perhaps, after renaming it for easier understandability. A view object that initializes all of WebKit only 1 way is not good. 2. WkContext and WKPageGroup are key to obtaining a configurable Qt port around WebKit2. Why? A correctly initialized WKContent is the gateway to cool features like (a) Memory caches which are configured automatically to match your application complexity (see (1) above). (b) Enabling or disabling advanced features like geolocation which a Mail application (for example), may choose to turn it off. (c) Injected Bundle shared libraries which seem to be an incredibly rich way to extend WebProcess side functionality while still letting the application "own" the code, not compiled into QtWebKit's shared object. (d) Any information which the WebProcess needs before it starts up (like say the path to the HTTP cache) Additionally, WKPageGroup is also critical, because it allows control of: (e) Preferences, which are a superset of what we used to have with QWebSettings in WebKit1 (f) Allow an advanced user (such as browser) to have a PageGroup for chromeless "app mode" pages, and another PageGroup for normal web pages. In summary, it may be desirable to: a) Make a three way choice between lite, medium and advanced use accessible to the QML users as a supported API. b) Enhance our current QTouchWebPage/View C++ interface to allow initializing a non-default WKContext easier, say one with a specific (memory) cache model or path for the injected bundle. What you do think? Regards, Siddharth PS: There is only one WKContext per UI process in the "shared web process" model currently in trunk, i.e WKContext is effectively a singleton at this time. _______________________________________________ webkit-qt mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
