Anyone knows the future of Qt Webkit?
-
Hi,
i am developing a web browser like application and while playing around with the new QtWebEngine which seems to be made to replace Webkit sooner or later seems to have so many drawbacks or missing features that i need. While some of them may not be here yet, some of them might never (like changing proxy for each page, seems to be a command line parameter with QtWebEngine).
I found a blog entry that said, that main development would be on WebEngine from now. But what about new webkit feautures (actual html5 features of the webkit engine) will they go into QtWebKit as well?
Is it a good idea to start a application which main use is rendering webpages based on the Qt Webkit system today?
-
Hi,
QtWebKit is declared deprecated in Qt5.5; this means that in the future this module will be removed from the standard Qt modules.
I don't know when this will happens but IMO not before Qt 6. Anyway I think this module will be not upgraded in the next versions of Qt.
About missing features you could ask to the WebEngine team if there's a plan to implement them.
-
You are absolutely correct. There is no comparison between QtWebkit and QtWebEngine. QtWebEngine is a completely different API and lacks so much it is virtually impossible to substitute it for QtWebkit. This decision to go this route is poorly thought out and no consideration was made for existing applications that rely on the outstanding integration features of QtWebkit and Qt. Furthermore the latest 5.5 release has completely broken WebKit integration so as the make it unstable and unusable. What works fine in Qt 4.8 crashes repeatedly inside WebKit. So for now we have had to go back to Qt 4.8. IMO Qt 5.5 is a disastrous release. Totally unstable.
-
I am using QtWebKit since Qt 5.2.0 in my Desktop Application. Right now, it seems that whichever Qt Version is the last one that contains QtWebKit, will be the last one I install.
There is no Alternative for QtWebKit right now.
In addition, I am not sure If there will ever be a Alternative for those who want to stay with MinGW.
I dont want to use MSVC (using MinGW on Windows 7 and Windows 10). My experience with MSVC always required to make some nasty kind-of-workarounds to build my Stuff. Yes I hate MSVC.If they (Digia) dont find a way to make QtWebEngine available on MinGW, I (probably) have to find an Alternative to Qt. Which will be sad as the Qt Project is a great one overall.
But yes, Qt 5.5 is a "strange" Release. While I compiled it, I got a couple hundreds of Warnings regarding to set but unused Variables, deprecated Functions, bad conversions etc. etc. on more than one Module. Even more Warnings as with Qt 5.4.1 (5.4.2 untested).
And lastly: Not 100 percent sure but I think that I have read somewhere, that QtWebKit will finally be removed with Qt 6.0. So it will be officially available for a while.
Oliver
-
@SGaist That may well be the reasoning but where does it state that using QtWebEngine requires MSVC2013 and it only can be used 64 bit? Its not even included in Qt5.5 x32. Nowhere that I can find any mention of this.
Now this is strange too as I have integrated v8 into my Qt application and I have built that 32 bit.
So the issue is not just the deprecation of QtWebkit but the deprecation of 32 bit platforms and the need to build with MSVC2013 which btw produces code that will not run on XP.
So this decision to deprecate QtWebKit has had many knock-on affects.
If it was just a simple matter of re-architecting (a large and complex application) to use QtWebEngine I guess thats what we need to do (albeit its messy) but the fact is there is no 32 bit support for QtWebEngine and there is no build support for mingw.
There should be a big "warning" sign on the downloads page regarding this as its vitally important and is hidden away. Correct me if I'm wrong.
-
@SGaist Reading that blog article and following the link to the wiki for QWebEngine http://wiki.qt.io/QtWebEngine There is no mention that this is 64 bit only. Am I missing something obvious here? Is there a 32 bit build available but only in the VS installer not the mingw installer? Can someone clarify this as I build using the mingw toolchain.
-
The precompiled Qt 5.5 MSVC 2013 Packages contain precompiled WebEngine .dll's
The precompiled Qt 5.5 MSVC 2010 and 2012 Packages contain the Source Files for WebEngine (like the MSVC 2013 Package does)
but NO precompiled WebEngine .dll'sYou can get the Package as well as the Source Code from here:
from the Qt Download Site
The Source Code Packages are found in the 'single' Folder.MSVC 2013 is the minimum Version that is required to build QtWebEngine. This dependence is hardcoded in the Chromium Engine. This was done by the Chromium Developers (mainly Google at the the time development started).
Unless a lot of Code has been changed (which definitely will sadly not happen as it currently stands) in the Chromium Engine,
there will be no Support for MinGW and for MSVC Versions below 2013.EDIT01: There was was a hint on the 'Qt 5.4 Changes Wikipage' about MSVC 2013 and Chromium. I dont know why this has been removed. Strange
-
Thank you for taking the time to answer my question. It is strange that this is not mentioned anywhere on the downloads page or the release notes. So the precompiled packages you are referring to are both 32-bit and 64-bit of just 64-bit?
-
@coquetangler
The above mentioned MSVC 2013 Package is for 32-bit. The 64-bit Version is called 'qt-opensource-windows-x86-msvc2013_64-5.5.0.exe'.It was mentioned in a couple of Places. They moved the old Wiki Pages to a new Wiki Engine. A lot of Stuff has been "lost in Translation" so to Speak.
-
Thanks for your help.
-
@Heiko93 I experimented with the Qt 5.5 tech preview of the QML QtWebKit (not to be confused with the embedded webkit in QWebView widget). I found some quirks with it that make it pretty much unusable in a normal production environment. I hope these quirks don't continue in the next version of Qt after Qt 5.5. I like the strategy of it, however, because if you want to get an iOS app approved, the Apple Store requires that you use native webkit that's in the operating system, not ship with Chromium or an embedded webkit. It also makes sense on Android, too, because why make your APK package have to install its own Chromium or embedded webkit (making it pretty fat) when there's already a webkit in the OS? As for OSX, it also has an embedded webkit in the OS (Safari uses it), so it makes a slimmer install if you can use QtWebView (native webkit) instead of QWebView (embedded webkit) or QtWebEngine (embedded Chromium).
For now, unless the direction changes in a future version of Qt beyond 5.5, this looks like the most stable route:
-
OSX. Build a widget-based app with QWebView widget. It's an embedded webkit, but she works and doesn't have the quirks. Plus, it's got a neato C++ bridge. I'm not certain yet whether Apple will allow an embedded webkit in their Apple Store for OSX. I'm waiting on their callback. The docs for Apple Store seem to point out the webkit issue is only for iOS, not OSX.
-
iOS (and want to get it approved in the Apple Store). If you can live with the quirks of QtWebView in QML, you'll get native webkit support from the iOS operating system. It makes a thinner install, too.
-
iOS (and don't care about the Apple Store). Use the embedded webkit from Qt with a widget-based app and QWebView widget.
-
Android (and care about Google Play approval). Use the same technique for iOS and Apple Store approval -- native webkit with QtWebView.
-
Android (and don't care about Google Play approval). Use the same technique for iOS and not caring about Apple Store approval -- embedded webkit with QWebView.
-
Windows or Linux. These don't have an embedded webkit that I'm aware of. So, use QWebView (the embedded webkit) widget in a widget-based application for now, and migrate to the QtWebEngine later on. As for whether QtWebEngine will have quirks or not -- I still wait to see. When I'm talking quirks -- things like scrollbars that disappear when you want them, controls that don't work, controls that look wonky, not able to disable the rightclick context menu, not able to disable some keystrokes that make the pages go backward and forward, and not able to disable the zoom effect when you doubleclick the page.
-
