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