Qt-contributors-summit-2013-Qt Web Engine

• 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 APIs 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 API 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 API 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 API too limited, WebKit 1 API too broad. What we would like to have? -> discussion to be continued here:http://wiki.qt.io/QtWebEngine/

• QWebEngine going forward:
  • need for sandboxing, security in general.
  • for API 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 HTML, problem: objects live in a different process. We could add API 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 API 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 QNAM in hybrid apps / in general? Ideally have only one HTTP 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 API could be deprecated in favor of Chromium; API 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 API!

Going forward

List of use cases and APIs to consider [qt.io]

Trello board [trello.com]