[Development] Deprecating modules with 5.5
Kevin Kofler
kevin.kofler at chello.at
Thu Feb 5 15:19:08 CET 2015
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
More information about the Development
mailing list