https://bugs.kde.org/show_bug.cgi?id=363859
--- Comment #27 from caulier.gil...@gmail.com --- Some details about the problem seen with QtWebEngine port : 1/ The DK bundles explode. It's increased to 100Mb. QWebEngine need to be optimized at compilation time. There are a lots of possibilities due to the huge dependencies list. Also, QWebkit use 5 .pak files with binary data. It's not a negligible size. Why ? I don't know yet. 2/ QWebEngine use a run time dependency and... dbus. This is really weird. There is a stand alone executable dedicated to preload pages in memory (if i well understand). This make AppImage not really easy to run. I found a solution but i'm not happy with it. It's not really optimum. I'm not alone with this problem. I'm in contact with AppImage lead developer who maintain a CI suite to package application as bundle, and most of Qt5 applications have a problem with this QWebEngine dependency. The quick solution is to remove this dependency and make code optional. This is not acceptable for digiKam. As i understand, a call to Qt to make this framework better compatible with bundle solutions was reported. 3/ There is a crash in QWebEngine when digiKam is closed. It's inside libudev. I don't know why yet... 4/ Marble is not yet ported to QWebEngine and still use QWebkit to render some parts inside. This will cut Marble features, and we don't want to include both framework in the bundles. 5/ The time to compile Qt explode with QWebEngine : 1h36 with QWebkit, 3h15 with QWebEngine. Same VM under Centos 6.8 running on same computer. So i must conclude that we need more time before to use QWebEngine inside digiKam. The best solution is to provide code for both QWebkit and QWebengine and to create a switch between both frameworks at compilation time. QWebkit must be the default one. I propose to make another try with Qt 5.10 and DK 6.0.0 Gilles Caulier -- You are receiving this mail because: You are watching all bug changes.
