QtWebEngine in kdepim

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 🙂

18 Responses

  1. tosky says:

    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. laurent says:

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

  3. blaze says:

    >QtWebEngine in kdepim

    pls no, just revive KHTML

    • avlas says:

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

      • laurent says:

        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 🙂

      • blaze says:

        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.

        • laurent says:

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

          • Markus S. says:

            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. takanowaka says:

    Re: Distros and QtWebEngine
    https://lwn.net/Articles/643479/

    • laurent says:

      Not the case for Qt5.6:)

      • blaze says:

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

        • laurent says:

          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. Fabian says:

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

  6. Vojta says:

    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.

    https://github.com/annulen/webkit

  8. Ahmed says:

    I just updated to Kubuntu 17.10 and saying that Akregator “works fine with QtWebEngine” is extremely misleading, to say the least. Updating to Frameworks 5.39 through backports didn’t fix anything either.

    Where do I start?

    Since the update, I’ve regularly had my feeds corrupted, according to a popup that shows when Kontact is started, and they all reverted to the default ones (kde-related, debian, planets, etc…), losing all I had.

    When it “works”, most of the articles have problems with the date (this is a known bug from 7 years ago at least, https://bugs.kde.org/show_bug.cgi?id=256034).

    The unread message counts sometines get out of sync and they take a lot to update, or they never update, which makes the “go to next unread” and other shortcuts not work.

    There’s also a very annoying reported bug about scroll not going back to top when switching articles.

    And to put the nail in the coffin, for some reason most of the times the Article main menu entry appears all greyed out and it’s not possible to do anything with the articles (delete, mark as important, send, etc…) and none of the shortcuts work. The same happens on the feeds list, you can’t delete feeds.

    So I think you should change the part where you say Akregator “works fine with QtWebEngine” because it’s just not true, and reading it here is one of the reasons that made me try to update, leading to a disaster.

    Thank you.

Leave a Reply

Your email address will not be published. Required fields are marked *