[webkit-qt] APIs going forward

Simon Hausmann simon.hausmann at digia.com
Tue Feb 5 01:03:06 PST 2013


On Tuesday, February 05, 2013 09:39:15 AM Sergio Villar Senin wrote:
> En 04/02/13 11:13, Simon Hausmann escribiu:
> > 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?
> 
> So if I understood it correctly, the plan is to export the whole C API
> and then have a small subset of it available through QML which will
> cover most of application use cases. That sounds more than sensible and
> I'd bet that it will make most of the users happy.

Yes.
 
> But, the potential issue I see is that the C API does not currently look
> as stable as it was supposed to be (because of the recent changes in WK2
> governance). I don't know much about the Qt project policies but I guess
> that if you provide some API in a stable release you'd have to support
> it for some releases. What's the plan for that?

The C API is not subject to the policies of the Qt project (it cannot be). 
Therefore it would for example not be available when you do QT += webkit in 
your .pro file. We could choose to make it _accessible_ when using QT += 
webkit-private.


Simon


More information about the webkit-qt mailing list