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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development