[Qtwebengine] Hopeful of a timeline?

Philipp A. flying-sheep at web.de
Tue Jan 6 18:03:22 CET 2015

2015-01-06 12:19 GMT+01:00 Jocelyn Turcotte <jocelyn.turcotte at digia.com>:

> 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.

yeah, thanks for the trello link!

it’s strange though: https://codereview.qt-project.org/#/c/97486/

this is listed under “done in 5.4”, but acceptNavigationRequest only exists
in the dev branch…

 For simple web contents yes, but more advanced content like WebGL and
> multimedia soon gets problematic.

OK, but that’s even more reason to want a component that can all that *and*
everything QtWebkit was able to do :)

 What you consider cruft is important for other people, and vice versa.

You misunderstood me: i meant that, like every rewrite, QtWebEngine surely
had some architecture cleanups born from lesson learned while developing

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.

What are you getting at? Seems that many important things are in the
“doing” or “todo” categories in trello.

> 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.

Ah, interesting. so why switch to chromium where this promise possibly
(IDK, please tell me) doesn’t exist?

Seems like giving up an advantage, but i’m sure you had your reasons!

> 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.

well, chromiums public API is relatively exensive, so i’m pretty sure one
can implement many things on top of it. (if you mean

> Jocelyn

thanks for the explanations,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qtwebengine/attachments/20150106/8763ec72/attachment.html>

More information about the QtWebEngine mailing list