Abstract from direct use of QtWebEngine
Open, Needs TriagePublic


KDEPim started to heavily rely on QtWebEngine. I think it would be better, if an abstraction, say KWebPage were introduced, which could be built against QtWebEngine, QtWebKit, and what ever will be the hot-new-thing two years down the line.

There are multiple reasons I think this would be a good idea

  • FreeBSD&Co do not have WebEngine -- which blocks us from providing up to date KDEPim. [1], and possibly more applications every new KDE Applications release cycle.
  • Who knows how long WebEngine is the thing
  • Less code duplications (every application seems to write more or less the same code to restrict the capabilities of WebEngine)
  • Some people may have [security] concerns with being required to use google code to run KDE

Such an abstraction was started by @apol for kdevelop in D5042.


[1] I invite people to glance at the chromium sources, before telling me just port WebEngine to FreeBSD :)

tcberner created this task.Apr 10 2017, 4:53 PM

Generic abstraction for web engines does not work. If it would, then KDEWebKit would've been simply ported from QtWebKit to QtWebEngine, or even Qt would've only replaced the guts of QtWebKit with WebEngine. But between WebKit and WebEngine you have major architectural differences that prevent you from having a generic abstraction - the best example is the out-of-process rendering introduced in WebEngine, which prevents synchronous DOM manipulation and therefore there's no DOM manipulation API at all in WebEngine like there was in WebKit. In KDE PIM we had to switch to ugly and slow dispatching of JavaScript snippets (@mlaurent could for sure expand on this). Sure, you could write a wrapper for QtWebKit that would emulate the asynchronous WebEngine API. But when The Next Big Thing comes and introduces yet another new thing that's incompatible with WebEngine, what do you do then? Wrap that in another layer of abstraction? Don't take me wrong here, I sympathize with your issue and with my PIM dev hat on I am actually sad that FreeBSD users cannot use the latest greatest KDE PIM. But this is not just an excuse to avoid more work. I've been in this situation before couple years ago when I was porting Evolution from GtkHtml to GtkWebKit, and I can tell you there is a recurring pattern when switching to modern rendering engines - there is always functionality that the old one does not have, can't have or simply won't have and you can't emulate it unless you want to write ridiculous amount of code. And I can say with a lot of confidence that the same will happen when WebEngine will be replaced by The Next Engine. And don't let me start on covering rendering differences, which you can't easily affect from outside the engine code, and you need complicated testing infrastructure for that....

If you can write an abstraction for QtWebKit and QtWebEngine that emulates missing features of WebKit and guarantees consistent behavior and rendering output for both and you would maintain such a framework for years to come, then I'll happily spend all my free weekends to port the whole KDE PIM to it.

Finally, in the case of PIM you *must* consider security. While KDevelop only shows a local, generated HTML documentation and could easily use QtWebKit for that, KMail and friends are rendering data from the Evil Internets, and that's the last place where you want to compromise on security.

PS: this is my view as a PIM dev, @mlaurent has the final say in this as he maintains the relevant components and has spent a lot of time migrating to WebEngine

In kmail/akregator it was not just a replacing from QtWebKit to QtWebEngine.
We use a lot of async method now (before sync)
We use a lot of javascript support now (still fixing some bugs last week).
For sure as we create specific html and using javascript for get data etc.
It will not easy to creating an abstract interface for all.

For example all code was ported to async code in templateparser for removing all qrtwebkit.
So for me you will add a code hard to maintaining in the future.

So I don't want it for kdepim.
As I think that I will continue for the future to maintain it I don't want to maintain 2 engine as I think it's obsolete and it will remove in qt6 (in 2 years)

I don't want to make more work for me :)
So sorry I am against one it.