[Development] Deprecating modules with 5.5

[Robert Knight]

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

These are all valid concerns but ultimately of secondary importance to most
app developers
who care most about delivering working software to their end users and for
them the OS X / Windows
model of bundling anything not guaranteed to be part of the base platform
works quite nicely.

We ship a complete copy of Qt in our non-open source app for Linux and a
runtime wrapper that will
choose on the fly whether to use it or not. Because of that we are able to
offer a _better_ experience
for our users than packaged open source software, which sucks.

I'm not super enthused about shipping what is effectively a big chunk of an
operating system as part of an
app, but I can't disagree with Lars' comments about the effort required to
maintain a modern browser engine.

On 5 February 2015 at 16:08, Kevin Kofler <kevin.kofler at chello.at> wrote:

> 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
> KDE.
>
> 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
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20150206/1882e420/attachment.html>