[webkit-qt] APIs going forward

Simon Hausmann simon.hausmann at digia.com
Mon Feb 4 02:13:35 PST 2013


I see an increasing demand in exposing features in the QML API. Some of those 
features don't really fit naturally in it but are necessary to accomplish what 
seem like basic tasks. Consequently we're facing a difficult time between finding 
an intuitive QML API, keeping things slim and maintainable but still making it 
possible to do certain things.

At the same time on the implementation side we're seeing the need to improve 
our layering and encapsulation. It is our intention to separate the QML 
specific bits in WebKit2 from the non-QML specific bits and use a similar 
layering as the other ports between then, i.e. 90% of the functionality is 
covered by the C API and the remaining 10% are covered by a (Qt) port specific 
view class.

So how are the two related, demand of richer API and "implementation details" 
of the QML webview?

Well, if we do this right then the QML2 webview would be implemented on top of 
a semi-stable 90% C based API that is shared between all ports of WebKit2. 
That changes how we can perceive WebKit as a library in the system:

    (1) It looks like a "third-party" library that uses Qt, provides a mostly 
C based low-level API that provides strictly speaking no stability guarantees 
but gives full access to WebKit. Think of it as a library like libpng or 
libicu, it just happens to use Qt under the bonnet.

    (2) A separate QML2 integration is based on the same API and connects 
WebKit with QML. It comes with the full Qt API promise of stability and 

The separation allows us to keep the QML API minimal and simple, following one 
of the Qt principles that the common things should be easy to do. If you need 
more then you'll have to fall back to the underlying library that provides a 
lower level API. If done right it would be possible to combine the two, i.e. 
if you'd like to use the QML webview in your application but need to fine-tune 
one aspect really specific to your use-case (say the cookie storage location or 
making sure that you have a dedicated web process), then you would be able to 
connect the QML webview with the underlying WebKit2 C API that.

How does that sound?

If you're interested in helping us take this direction, feel free to join the 
hackery and use the master bug at 
https://bugs.webkit.org/showdependencytree.cgi?id=108471&hide_resolved=1 for 
tracking and coordination (as well as IRC naturally).


More information about the webkit-qt mailing list