Qt-contributors-summit-2013-Qt Web Engine: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
No edit summary
m (Categorize)
 
(2 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{Cleanup | reason=Auto-imported from ExpressionEngine.}}
[[Category:QtCS2013]]
* 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? -&gt; 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]''

Latest revision as of 17:28, 6 January 2017

This article may require cleanup to meet the Qt Wiki's quality standards. Reason: Auto-imported from ExpressionEngine.
Please improve this article if you can. Remove the {{cleanup}} tag and add this page to Updated pages list after it's clean.
  • 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]