QtWebEngine in kdepim

As QWebKit is deprecated now (it’s not in official 5.6 package, but we still able to build by hand for 5.6 as distro will do) I investigated how to replace it by QWebEngine.

For sure QWebEngine  < Qt5.6 was not enough to replace it in akregator or others kdepim component.

For example QUrl custom scheme was not supported until 5.6.

So I decided to start porting kdepim against QtWebEngine. Some parts were easy as “about page” in kontact, others were harder as akregator support or others parts were not started yet (as remove QtWebKit in kmail for example).

This big problem is that QtWebEngine uses async method when QtWebKit used sync method.

So it was necessary to rewrite a lot of part of code (still in progress).

But my big success is Akregator which works fine with QtWebEngine.

In kdepim/messagelib/kdepimlibs I added an option for activate it. But it will not activate by default for 16.04 as it’s still not perfect yet.

I will continue this work until 16.08.

There is still a lot of work as:

  • reimplement adblock support (in progress)
  • reimplement accesskey
  • rewrite mail viewer to support it
  • rewrite blogilo lib based on QtWebEngine.

But it’s good and fun to do it 🙂

Leave a comment ?


  1. Thanks for your work on the PIM components. I understand the complication, but whenever you can, could you please make sure to have a switch to turn off QtWebEngine support without disabling an entire application?

  2. We have two supports 🙂
    For sure I didn’t disable application. I kept qtwebkit support too (for 16.04) 🙂

  3. >QtWebEngine in kdepim

    pls no, just revive KHTML

    • What is the problem of QtWebEngine? I don’t know but I guess that reviving KHTML would take a lot of effort

      • good question 🙂
        For sure khtml is dead for me.
        I ported akregator from khtml to qtwebkit for next 5.2, and I worked now for 5.3 to finish port to QtWebEngine.
        but for sure I never will readd khtml 🙂

      • It’s total overkill. Not even web engine actually but full heavy browser. Yet still will be updated only once in a while and therefore will be vulnerable. Complaints of distro maintainers not to be forgotten here. Maintaining a number of chromium browsers in one single distro is another big overkill here.
        PIM doesn’t need real web browser. It needs quick and lightweight rendering engine.

        • “PIM doesn’t need real web browser. It needs quick and lightweight rendering engine.” and buggy, slow, security vulnerability 🙂

          • QtWebEngine never uses the current Chrome codebase. It’s always months behind and therefore exposes security leaks of the world’s most used (and in turn most attacked) web browser over a significant amount of time.

            If security is your concern, you should use QtMozEmbed. Distributions can simply ship this based on the latest Firefox ESR code.

  4. Re: Distros and QtWebEngine

    • Not the case for Qt5.6:)

      • You know what, Qt5.6 is already packaged for Debian (experimental) and there are no QtWebEngine. How KDEPIM supposed to work in that case?

        • 5.6 is not released yet.
          But if debian is never happy it’s not my problem.
          Qt has changed code for allowing to compile with lib from system but if they had some other problem…

          Redhat will provide it.

          So indeed if debian doesn’t like qtwebengine it will be a problem for Debian not for kdepim.

  5. i just have to say this:
    Thanks for this work – i love you :’D

  6. Thank You for Your work. It sounds great. How will this transition be related to Konqueror 5? What will it use as the rendering engine?

  7. I’m working on QtWebKit update to current WebKit trunk. Widgets API is already functional.


Leave a Comment

NOTE - You can use these HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>