Knoll Lars wrote: > But we don’t really have a choice, as there is no upstream for Qt WebKit > anymore. This implies that we’d have to fully develop that fork on our own > to support is. That in turn requires a team far larger than what we have. > So it’s simply not doable.
The thing is, QtWebEngine is also a problem for Fedora, because we do not even have Chromium in Fedora because it bundles so many libraries, and in QtWebEngine, you bundle Chromium! Bundled libraries are not allowed in Fedora (nor Debian, for that matter). So we do not currently have QtWebEngine packaged in Fedora and I'm not convinced that we will ever have it. (We have a specfile, but it does not comply with the project-wide bundling policies and as such will likely not pass review.) Both QtWebEngine bundling Chromium, and Chromium itself bundling lots of other stuff are blockers. QtWebEngine also has some additional regressions compared to QtWebKit: * no GStreamer support, instead relying on a custom FFmpeg that is hard to add additional codecs to (whereas for GStreamer, the user just needs to install the plugin packages that are used by all GStreamer applications), * no QNetworkAccess support, and thus no way to plug in KIO support. So it is hardcoded to support only the protocols Chromium supports out of the box, no way to add additional ones (man:, info:, gopher:, etc.), * no support for our secondary architectures, due to the V8 dependency. Relying on Chromium is a horrible idea. If we had been asked beforehand (we only learned of it when the big, secretively developed code drop was unveiled), we would have told you immediately that Chromium is a no go. For the "no upstream" issue, is it not possible to work together with WebKitGTK+? They are sticking to WebKit, aren't they? Kevin Kofler _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development