[Development] Deprecating modules with 5.5

[Knoll Lars]

On 05/02/15 15:19, "Kevin Kofler" <kevin.kofler at chello.at> wrote:

>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.

It wasn’t secret at all. We blog’ed about it before we started, and did
the development in the open.

But we don’t have much of a choice, if we want to deliver an up to date
web engine. With Qt WebKit we would have needed around 5 times the people
to keep it working and in a state that is competitive. This was pretty
much the only way we could keep an up to date engine going with the amount
of people we have.

I understand that you have certain policies, but the reality out there is
that a certain level of pragmatism is required if you want to get a usable
and competitive product.


>For the "no upstream" issue, is it not possible to work together with
>WebKitGTK+? They are sticking to WebKit, aren't they?

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.

Cheers,
Lars