[heads-up/question] QtWebKit deprecated? Not anymore!

[RJVB]

Hi,

Something I discovered a few days ago and that got me quite excited as I'm not very happy at all with the "somewhat" bloated QtWebEngine:

https://github.com/annulen/webkit/wiki

In short, WebKit never stopped being developed, and efforts have been underway to bring the Qt bindings up to date with this development. The WiKi above lists a number of reasons why this is interesting, which isn't only because of the fewer resource requirements.

I've been doing some comparisons of this new WebKit and the 5.8.0 WebEngine in Konqueror5 and I cannot really tell which one works better or worse.

Is there any chance you'd consider bringing back support for QtWebKit, as a build option or even a runtime option (Konqueror5 actually supports "previewing" a page with one of the other backends that the click of a menu)?

[nowrep]

No, QtWebEngine is better suited to be used for web browser.

[RJVB]

did you realise that, @annulen =)

[annulen]

Oh no. This means everything was in vain :(

[nowrep]

Yeah well, not really :D QtWebKit is better for almost every use case except full web browser. And even if/when it gets WebKit2 C++ API it will have the same limitations as QtWebEngine, so there is no reason to use it in QupZilla.

[annulen]

Actually, in WebKit2 it's possible to run user code inside web process, so everything that is possible in WebKit1 can be done, e.g. QWebElement and friends. The only thing which won't be possible is using custom QNAM, because network works in another process (but this should not really be a problem because there are other ways to hook there. See https://github.com/annulen/webkit/wiki/Interesting-things-you-can-implement-in-QtWebKit#full-fledged-c-api-for-webkit2-including-webprocess-side

FWIW WebKitGTK have completely migrated to WebKit2 since 2014, and this approach allowed to port most existing applications

[annulen]

(But don't think I'm advocating use WebKit2 in RSS viewers or email clients, I think it's rather dumb)

[annulen]

And actually there is C++ API for WebKit2 and one could use it inside widgets application since the moment when QQuickWidget was introduced (QT += webkit-private and add QQuickWebView to QQuickWidget). It provides everything that is available for QML and even a bit more. But still very limited (and currently even more limited then QtWebEngine).

[RJVB]

And even if/when it gets WebKit2 C++ API it will have the same limitations as QtWebEngine, so there is no reason to use it in QupZilla.

I'd say that depends on resource use.

To put it bluntly: QtWebEngine is basically "QtChrome", so has the same limitations as Google Chrome (but most likely a few more), so what's the reason to use QupZilla (or any other similar browser which will probably never be as full a browser as one of the big brothers)? Manage to reach those limitations while requiring significantly less resources and all of a sudden there is a compelling reason to use browsers like that.

(So, Safari isn't a full web browser anymore? O:^))

[annulen]

Safari isn't a full web browser anymore?

Safari uses WebKit2 since 5.1