Qt wiki will be updated on October 12th 2023 starting at 11:30 AM (EEST) and the maintenance will last around 2-3 hours. During the maintenance the site will be unavailable.

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

From Qt Wiki
Jump to navigation Jump to search
No edit summary
 
No edit summary
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? -&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]''

Revision as of 13:59, 24 February 2015

Retrieved from "https://wiki-qt-io-staging.herokuapp.com/index.php?title=Qt-contributors-summit-2013-Qt_Web_Engine&oldid=5697"