KDEPIM/KMail is NOT dead

This week I received several mails about kmail/kontact user which read the blog “The year of Kube” and asked me if “KMail is dead now?”. Or “KMail will be replace by Kube in the future?”

I answered that KMail and KDEPIM are still alive and they still continue to be maintain. We prepare actually the next release 16.04 with a lot of changes as:

  • all library are split for helping new developer to use them.
  • we created a system of plugins for kmail/kaddressbook/korganizer and we moved a lot of codes in theses new plugins (so we reduced code complexity in base application).
  • Akregator was refreshed (bugs fixing, move to qtwebkit rendering html, clean up UI)
  • New kmail quote support (modernize quote support as others mail applications)
  • Bug fixing and bug fixing.

So for sure kdepim/kmail is not dead.

 

What is Kube ?

Kube is a new project which started from scratch by the KolabSystem team, based on new backend named AkonadiNext which was renamed as Sink (developed by the KolabSystem team), and it uses QML as technology.

For the moment Kube is just a new email client.

They want to reimplement a new mail client and perhaps other pim components in the future.

They use some codes from kdepim (for example some part of code from the library messageviewer to rendering html).

We decided some months ago to split kdepim libraries to help external applications to use them (We knew that Kube wanted to use some part of codes). We didn’t want to see a fork of kdepim library.

 

What is KMail/Kontact/KDEPIM ?

It’s a suite of PIM application based on Akonadi technology

Kontact regroups some application as:

  • KMail: kde mail reader
  • KAddressBook: Address Book application
  • KOrganizer: organizer application
  • Akregator: Rss reader
  • SieveEditor: an sieve editor script
  • Kontact: an application which embedded kmail/kaddressbook/korganizer/knotes/akregator
  • PimSettingExporter: an application which import/export settings.
  • and other little programs.

KMail is the official KDE mail reader from long time.

 

Why we don’t switch to Kube and we didn’t kill kdepim/kmail ?

Because in Akademy 2015 we didn’t decide to do it. We decided to migrate step by step (on several years) to next backend but not start from scratch a new application. (It’s always critical to migrate to new technology so we take time).

We can’t migrate kdepim application directly without to be sure that new backend is ok and it works fine.

We can’t migrate to Sink if there is not a migrate application for existing data.

We can’t migrate to new backend if we are not sure that all resources are reimplemented (vcard resource, caldav resource etc.)

KMail/KDEPim is used from age. So we will not switch/break all in a release. We have a lot of users which will not understand if we trash all.

 

Future of KDEPIM?

We will continue to improve each components.

We will continue to read bugs reports and answer to user about them.

We will continue to add new features when they are useful.

We will continue to clean up code, clean up GUI.

We will continue to make KMail and other KDEPIM free bugs, and stable.

We will continue to rewrite kdepim application to allow in the future to move to “Sink” if possible.

 

To conclude

KMail/KDEPIM applications will be still in kde for future release.

Kube will not replace KMail in KDEPIM.

Kube will continue to be improved as an opensource project as other opensource project.

Leave a comment ?

18 Comments.

  1. “They want to reimplement a new mail ” but why? Clearly kmail is not good enough (or is bad enough) for them.

    • My guess would be to have something working on top of AkonadiNext. the Kdepim team made it clear that work towards that goal will be incremental, and having a backend with no frontend is kind of pointless…
      Here’s to hoping code sharing works 🙂

  2. I gave up on kmail after the 10 thousandths “Akonadi is working fine” response while I had multi-gb akondai files, kmail would start up without folders…would not let me just send an email later, without SCHEDULING it….ridiculous. Filed bugs.

  3. > We have a lot of users which will not understand if we trash all.

    We prefer to be treated like people, like in: “We have a lot of users who will not understand if we trash all”. Thanks.

    🙂

  4. Awesome! Great news, thank you for this essential work! 🙂

  5. Good to know, I use it since a long time and I really appreciate it. No serious issues but this maintenance is still needed.

    Anyways a big thanks ! et Bravo ! 😉

  6. Great news! Will there be access to the split libraries soon? I would like to try out some development and the stated changes seem to improve the accessibility a lot.

  7. Disgruntled.Dud

    I had horrible experience with kontact, kmail, together with mariadb (the mysql replacement), “konstant” deaths can crashes of kmail, impossible to use it, its link to akonadi would die, break, impossible to use. kmail would segfault and die if akonadi connection gives any sql errors.. deleting the akonadi ~/. dirs also does not help..

    Had to settle for thunderbird.. seriously.. kontact and kmail CRASHING when akonadi does not behave nicely is not “the way to program things” …

    • Hello Disgruntled,

      Kontact and Kmail are packaged to work seamlessly with MySQL at the moment. The idea that MariaDB is a drop-in replacement for MySQL is not true as both project begin to go their own ways, and the KDE PIM team is not to blame for those projects’ differences. At some point, the packagers need to focus their resources and settle on supporting one database technology, and that’s MySQL. For the technical excellence behind the KDE PIM, using MySQL is a small sacrifice.

      • Hello Michael

        Forgive my ultra slow brain being fried in the summer heat – I just want to be absolutely sure.

        What you are saying is, that if a user (for instance me 🙂 experience daily Arkonadi lockups (for instance every time more than one PIM app is running) and craches – then it might be because my distro have changed their first choice of DBMS to MariaDB ?

  8. Using KMail is a pain, and has been for a long while. It’s broken. I have to restart KMail and Akonadi several times each day to get any e-mail. Some old mail is inaccessible. Some inboxes report unread e-mail that is not there. The list goes on.

    How one of the best mail clients got to a point where it’s unusable is beyond me.

    • I use kmail and mu4e side-by-side on the same maildirs. There are some things for which kmail simply wins, while for others mu4e is a win.

      I can even use Emacs in KMail nowadays (via embed).

      Furthermore, given that Thunderbird might be lost, I am really happy to see continued development of KMail. KMail might not be perfect, but it is already really really good.

  9. I gradually get also the impression that KMail is a pain. Used it for years but got different problems again and again. Currently (v5.1.3) no attached images are display in an html emails. Also the search does not seem to work. I don’t know what to do with it. I’m getting close to also give it up… 🙁

  10. I had stopped using kmail but decided to give it a try 2 months ago.

    On a desktop computer it was working “fine” (if we don’t count the fact that kaddressbook somehow was completely separated from kmail, so I had to manually copy the email addresses).

    On a laptop computer, it was making sure to kill the battery life completely.

    Then the update to 16.04 arrived and the mail resource was just crashing.
    I tried to remove all configuration and start again but it still kept crashing and not working at all.

    Honestly, it’s been several years and akonadi is still really really bad and only works for few people who have really really powerful machines and are very lucky.

    Don’t you think it’s time to be honest to yourselves and admit it’s time to move on?

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>