[Qtwebengine] Hopeful of a timeline?

[Jocelyn Turcotte]

Hello Philipp,

On Tue, Jan 06, 2015 at 12:40:56AM +0100, Philipp A. wrote:
> Hi!
> 
> 2015-01-05 19:18 GMT+01:00 Jocelyn Turcotte <jocelyn.turcotte at digia.com>:
> 
> > I have to note that QtWebEngine isn't a 1-to-1 replacement of QtWebKit,
> > principally because some very advanced features can't be set in stone
> > through a public API without risking huge future maintenance efforts as
> > Chromium evolves under our feet. It is quite a dragon to ride.
> >
> 
> I’m sorry to say that, but that’s awful to hear. I expected QWebEngine to
> be *more* powerful than QWebkit.
> 
> Things like cookie management and complete control over requests, as well
> as access to the devtools are essential features for every more complex
> application. and that’s just the obvious puzzlers that i immediately
> stumbled upon.

It will be more powerful on the web API completeness and reliability's
point of view, but some features like complete control over requests might
not be possible (and locked through a public API and binary compatibility
promise) unless the Chromium team already ship this feature to let us
believe that we can maintain only an API wrapper downstream. We believe
that we can't ship such downstream features forever without increasing our
bug count significantly over time. Basic cookie management and devtools
are however perfectly doable and are on the schedule for 5.5 already.
 
> The public API aims at solving the general use case of embedding web
> > contents in Qt applications,
> 
> 
> This is already solved by simple stuff like the QML WebView.

For simple web contents yes, but more advanced content like WebGL and
multimedia soon gets problematic.
 
> > but if you are developping a more powerful
> > application I encourage you to look at the code and dig further to get
> > access to functionalities that you need, keeping in mind that the
> > further you dig, the more likely you'll have to update your code between
> > QtWebEngine updates.
> >
> 
> So you’re saying that we need to compile our own version of QWebEngine with
> custom patches?
> 
> I think many people expected it to be QWebkit with API cruft removed and a
> new backend. but now we are in the sad position to have a deprecated
> QWebkit that can do what we want (except modern HTML5 because it’s frozen)
> and a castrated QWebEngine that can’t and possibly won’t ever be able to do
> necessary things (if i understood you correctly)
> 
> again: i don’t want to descredit the hard work that went into executing the
> switch, but i question the research that went into the decision to abandon
> something with adequate capabilities for something with less.

What you consider cruft is important for other people, and vice versa. We
have to find a good compromise between what we can maintain using the
money paid for Qt licences + external contributions and finding a set of
features that fits the needs of most Qt applications interacting with web
contents.

Some features can be made public with reasonable maintenance, some small
features can be implemented and maintain downstream and exposed through
internal interfaces to keep the flexibility of updating the design as
Chromium itself changes, but bigger features that matter only to a handful
of applications should be kept in a branch or custom patches.

QtWebKit was lucky to be maintained upstream with the promise of Apple and
Google not to break our tests (to their expense but for our benefit) and
with a lot of development effort from Nokia, but still it had difficulty
shipping more platform integrated web features like multimedia.

QtWebEngine tries to stay conservative to keep as much of Chromium's
reliability even though it is developped downstream, in a similar way to
how your application is developped downstream from Qt but with the
advantage of a public API.

Cheers,
Jocelyn