|
|
| Line 1: |
Line 1: |
| * state-of-the-art: webkit team in Digia is small, lot of work to keep up, playing catch up, and even that is hard. Becoming hard to push the Qt side of WebKit 2 <span class="caps">API</span>s moving forward while trying to keep on par with other ports at the platform level.
| |
|
| |
|
| * Investigating a path using Chromium instead of WebKit. Chromium simplifies platform abstractions (which we would not want to change anyhow because of lack of manpower).
| |
|
| |
| * QWebEngine state of the art:
| |
| ** just thin layer around Chromium (Quick and Widgets)
| |
| ** basic QEvent mapping works, more work needed for nice touch and JS gestures integration.
| |
| ** Chromium provides all <span class="caps">API</span> to do that as of now. Problem: with Chromium we are making a toolkit, no app, so slight divergence here with the Chromium project and other adopters. Content <span class="caps">API</span> prone to minor changes, but should be maintainable.
| |
| ** problem on iOS: we cannot ship another web engine; we could just use the native web view there. Some platforms might be restrictive about scheme handlers etc.
| |
| ** current QWebEngine <span class="caps">API</span> too limited, WebKit 1 <span class="caps">API</span> too broad. What we would like to have? -> discussion to be continued here:[[QtWebEngine/|http://wiki.qt.io/QtWebEngine/]]
| |
|
| |
| * QWebEngine going forward:
| |
| ** need for sandboxing, security in general.
| |
| ** for <span class="caps">API</span> of QWebEngine: need to define use cases: execute javascript?, custom network managers? etc. integration with QtQuick might be nice… need to pass values back to <span class="caps">HTML</span>, problem: objects live in a different process. We could add <span class="caps">API</span> on the JavaScript side in contrast to the Qt side, so Web elements can be accessed from C++
| |
| ** more use cases: run-time / browser on embedded, using <span class="caps">API</span> being standardized by the community (e.g. saving history), passing in own certificates
| |
| ** network layer: settings, cookie storage, proxy, authentication, request interception, custom schemes etc.
| |
| ** How to solve problem of <span class="caps">QNAM</span> in hybrid apps / in general? Ideally have only one <span class="caps">HTTP</span> stack per app.
| |
| ** downside of Chromium: it is really big; we could disable features like NaCl etc.
| |
|
| |
| * going forward with WebKit:
| |
| ** needs to be maintained for some time in any case, there are features in WebKit 1 that Chromium does not have and that could be tricky to match.
| |
| ** Current WebKit2 <span class="caps">API</span> could be deprecated in favor of Chromium; <span class="caps">API</span> would be similar but not exactly the same (inheritance from Flickable not so desirable as it brings tons of side effects, etc)
| |
| ** 2nd step: WebKit 1 would be put in “mainteneance” mode; i.e. only critical fixes like security fixes backported
| |
|
| |
| * Please send in use cases for web engine, so we can shape the <span class="caps">API</span>!
| |
|
| |
| ==Going forward==
| |
|
| |
| [[QtWebEngine/|List of use cases and <span class="caps">API</span>s to consider]] ''[qt.io]''
| |
|
| |
| [https://trello.com/b/5G9c1rkb/qtwebengine Trello board] ''[trello.com]''
| |