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

Hi,
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.

Regards.