Qt WebKit Looks To Be Making A Comeback

[phoronix]

Phoronix: Qt WebKit Looks To Be Making A Comeback

Within the upstream Qt tool-kit, the WebKit module was dropped in favor of Qt WebEngine that's powered by Google's Chromium "Blink" engine. While Qt WebEngine is still working out well for new development projects, it looks like Qt WebKit is being worked on for a revival...

http://www.phoronix.com/scan.php?page=news_item&px=QtWebKit-Next-Gen

[Emdek]

It's progressing nicely, the only really user noticeable missing feature comparing to legacy version from SDK is NPAPI support (at least for those who need plugins):

https://github.com/annulen/webkit/wiki/Comparison-with-QtWebKit-5.6

If someone would like to try it under 64 bit Windows then you can find experimental build here:

https://sourceforge.net/projects/otter-browser/files/otter-browser-weekly126/otter-browser-win64-weekly126-qtwebkitng.7z/download

Once they will hit some bigger milestone I'll try to prepare some precompiled packages for Linux too. ;-)

[SpyroRyder]

Why would you use this over WebEngine? Like more power to them if they want to do it but this seems like completely duplicating the work for no gain at all.

[Emdek]

@SpyroRyder, QtWebEngine has limited integration and it won't expose as much features as QtWebKit since Blink / Chromium is fast moving target (Google likes to break stuff).
Also as of Qt 5.7 it still doesn't support some basic features like... printing (at least it will support saving to PDF).
Here is (outdated) list of missing stuff (some items are now done, but not that much):

https://github.com/OtterBrowser/otter-browser/wiki/QtWebEngine-Wishlist

Plus QtWebKit has some other users too, which cannot replace it with something different for various reasons.

[carewolf]

Why would you use this over WebEngine? Like more power to them if they want to do it but this seems like completely duplicating the work for no gain at all.

The old WebKit1 API allows a few things neither the WebKit2 API nor Chromium can. By having WebKit work in the same process as Qt it can integrate much deeper, with QObjects injected into JavaScript, having QtNetwork work as the network stack, and using QPainter as WebKit's paint back end. All which are impossible in WebEngine, and all also being a burden to maintain, and doomed anyway as there was focus to move to WebKit2 even in QtWebKit.

[annulen]

The old WebKit1 API allows a few things neither the WebKit2 API nor Chromium can. By having WebKit work in the same process as Qt it can integrate much deeper, with QObjects injected into JavaScript, having QtNetwork work as the network stack, and using QPainter as WebKit's paint back end. All which are impossible in WebEngine, and all also being a burden to maintain, and doomed anyway as there was focus to move to WebKit2 even in QtWebKit.

Actually, it's quite possible to have Qt Bridge and direct DOM access in WebKit2, by using InjectedBundle API. WebKitGTK provides WebExtensions API allowing to load C plugin into WebProcess and communicate with it over WebKit2 IPC, and we could do it as well.

[GreatEmerald]

Oh come on, just decide on one. Don't have both. Compiling an entire web framework takes ages; I don't want to wait *twice as many ages* because of both! And that's normally in addition to having to compile a dedicated browser!

My netbook has Qt4Webkit installed, because Skype requires it for some dumb reason (rendering widgets or something), and it sure is not fun to have to recompile it on every point release over and over again. Ideally it would not be a part of Qt altogether, but rather be a shared library with browsers. Also be modular instead of monolithic, so that on security updates only a part of it would have to be recompiled, not the whole thing.

[FireBurn]

I switched to using Qt 4.7-beta then 4.7-rc and realised I couldn't compile the gui for apitrace as QtWebkit doesn't exist for 4.7.

[Awesomeness]

Our plan is to use stable branches of WebKitGTK as a base of our stable branches

Wow, finally sane people in charge.

[Emdek]

@GreatEmerald, you don't need to rebuild all Qt modules at once.
And yeah, some shared library with core part of WebKit would be best (distributions would love that, just one bigger chunk instead of three), but I'm not sure if it is feasible already.
Also it is true that both QtWebEngine and QtWebKit shouldn't follow Qt releases strictly (gluing them in the first place wasn't a good idea, at least not from all points of view), security fixes should get own separate releases ASAP, plus waiting like ten months for new feature release is pain (especially when QtWebEngine is still missing some basic stuff, earliest possibility to complete is Qt 5.8, which doesn't have release schedule yet on the wiki, but I doubt that it will make it before end of this year, perhaps February?).