[Development] Deprecating modules with 5.5

Kevin Kofler kevin.kofler at chello.at
Thu Feb 5 17:08:12 CET 2015

Knoll Lars wrote:
> Yes, and I am sure, they have huge issues keeping up with the development
> of competing web technologies. I’ve been there and done that with first
> KHTML, then Qt WebKit for many years. The fact is that HTML5 these days is
> a huge pig, and supporting all of it using WebKit and supporting 10
> different platforms is simply not possible with a team that’s smaller than
> ~50 people. We have tried for many years.

The thing is, if you want to deliver something that is suitable for 
distributions (which the current QtWebEngine is NOT!), you will need to fork 
Chromium, because upstream does not care about the issues.

Distributions such as Debian support many architectures. The Debian 
maintainers I've been in contact with over IRC were really unhappy to learn 
that QtWebEngine depends on V8. (They had not realized the implications of 
the announcement that it would use Chromium.) A JIT-only JavaScript engine, 
and browser code hardcoded to use only that engine (they removed the JS 
engine abstraction layer from WebKit and hardcoded V8 all over the place!) 
is horrible for portability. In Fedora, our primary architectures happen to 
be the ones V8 is targeting, but we do have secondary architectures on which 
we do not want to desupport large parts of Qt (such as Qt Assistant) and 

The bundling thing also really MUST be resolved. (At least the bundling of 
the many system libraries by Chromium. If you communicate that you have to 
bundle Chromium because you have to fork it to remove all the other bundled 
libraries, that will likely be a convincing enough argument to justify 
bundling Chromium.) It is just not practical to ship a second copy of dozens 
of system libraries, all built as part of QtWebEngine. This is a nightmare 
in terms of disk space, RAM use, potential for symbol conflicts and delivery 
of security updates.

We distributions also very much want the web browser to use our shared 
multimedia stack, i.e. GStreamer.

Then, the advantages of going with Chromium quickly start to vanish. IMHO, 
QtWebEngine is the one that should be deprecated.

        Kevin Kofler

More information about the Development mailing list