[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