[Qtwebengine] Hopeful of a timeline?

[Philipp A.]

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

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
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/public/
)

Cheers,
> Jocelyn
>

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