Category Archives: KDE

Answer about “Akonadi for e-mail needs to die” blog

Yesterday morning I read as usual before to hack on kdepim and I saw this blog.

I thought that it was a constructive blog, but not!

(As all your articles on your blog about kdepim. I don’t understand why you are not able to switch to another mailer before.)
Mr “Andreas K. Hüttel” is just an user which was frustrated by a bug about his IMAP server.

I can confirm that KMail is not free bug, Akonadi is not perfect too. We work a lot each days to fix the bugs. You can make the same blog about each application which doesn’t work as you want. You can criticize all these programs and wrote that developers lose their time to work on. I hope that you wrote some blog as it for Kernel Linux, Xorg, LibreOffice etc. for sure they are not perfect too.

KDEPIM team is small but I think that we make a good work. Perhaps you should read kde-commit to see all fixes that we did…

But Mr “Andreas K. Hüttel” I can tell you:

  • Nobody forced you to use KMail ! We are in open-source world, you are not happy by an application you can use another one!
  • I didn’t see a patch from you about KMail to try to fix it. So how can you told us that it was an error to migrate to Akonadi (just because it doesn’t work for you?). Did you study on which technology it’s based ?
  • When you wrote ” What is dead should better remain dead, and not suffer continuous revival efforts while users run away and the brand is damaged.” Who are you to tell us to stop to develop  KMail based on Akonadi ?
  • “Also, I’m a volunteer myself and invest a lot of time and effort into Linux. I’ve been seeing the resulting fallout. It likely scared off other prospective help.” Ok so I will wait to see your work about the fork of kdepim based on qt4. I am sure that you will able to make better than us (poor kdepim team). You know you can port it to qt5 and we will see if you will be able to fix all bugs not just your bugs. I hope that you will able to reproduce all of them.

Now Mr “Andreas K. Hüttel” with a blog as it you will discourage for sure some new user/developer, but also people  which helps us, they will think that they’re wasting their time. It’s unacceptable. 

Mr “Andreas K. Hüttel” you just have NOT ANY respect for all work done by the KDEPIM team, by the doc team, by the i18n team, by all user support guys, by the users which reported bugs.

Mr “Andreas K. Hüttel” if a day you are able to work on a project you will see that it’s not possible to reproduce all bugs because we don’t have all the time, we don’t have the same environment. Fixing a bug take time when we can’t reproduce when it’s a corner case. Some time we don’t have the good technology as a specific server IMAP etc. But perhaps it’s too hard for you to understand it.

Ok Mr “Andreas K. Hüttel” it’s sad that we were not able to fix your bug, but it’s more sad that you think that all kdepim team work is a lost of time.

As I wrote who are you to tell us that it’s a lost of time ?

Do you provide a technical solution ? NO

So for your information we will not stop to develop KMail because you think it’s a lost of time. We will continue, I will continue because I know that a lot of people uses it and they are happy with KMail based on Akonadi. I will continue to “lose my time” each day as I respect users which use KMail, it’s not your case.

I want to thank all people which participate, all guys was participating  to KMail improvement. We make KMail better for sure. Thanks guys. Thanks Doc Team, Thanks I18n Team, Thanks User Team Support, Thanks happy users, Thanks not happy users which understand our work.

To conclude we are in open-source you are not happy you can use another application, all developer is  able to choice on which technology he wants to develop, but it’s really unacceptable as you reduce kdepim team work (and other teams) to a lost of time because you are just a frustrated person.

News about kdepim: Allow to build standalone each applications


I worked harder during 6 days to allow to build each kdepim application as standalone.

I merged some sub-directories in other directory (for example agents in KMail. The agents depend against KMail), I moved some code in kdepim-addons etc.

This morning I added Superbuild support it’s a macro which allows to build each sub-directories as they were separate modules so we can test if build as standalone is not broken => all compiles fine.

Why I did it ?

It will help developers to compile just a module if he wants to debug/hack etc.

We continue to reduce difficulties to work on kdepim

When will I split in separate repositories ?

I decided to do it for 16.12 (it’s not a typo it’s not for 16.08). I prefer to be sure that all is ok before to process to split them.


How I can to build KMail (or others kdepim apps) as standalone in master kdepim git ?

It’s very easy, clone kdepim git master source:

git clone kde:kdepim.git

cd kdepim/kmail

mkdir build && cd build && cmake -DCMAKE_INSTALL_PREFIX=<path> ../ && make install


Status QtWebEngine in KDEPIM

As QtWebKit will be remove from official Qt package I decided some months ago to evaluate QtWebEngine.

For sure QtWebEngine < 5.6 was too limited. But I started to use it. I evaluated QtWebEngine 5.5 but some features were missing (as possibility to block request or use custom scheme url).

I started to focus on Akregator as it still used khtml, I migrated it to QtWebKit and after that to QtWebEngine. (For 16.04 there is a experimental option to activate compilation).

When I proved that it was possible to use in kdepim I started to port kmail. It was not easy as we use specific QtWebKit methods as QtWebElement which are sync method. In QtWebEngine we need to use async method.

So I started to create test application and autotests to validate my changes.

(For example I wanted to make sure that scamdetection works in QtWebEngine as it worked in QtWebKit).

Status in master

Akregator/Kontact/kmail can use QtWebEngine.

I created a new lib to replace composereditor-ng, named composereditorwebengine to make it possible to use QtWebEngine in Blogilo too. I finished it this morning.

I reimplemented AccessKey + AdBlock + ScamDetection support against QtWebEngine.


I will continue to fix, implement features. Not all is finished (but I use by default KMail QtWebEngine so I can see bugs and fix them).

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 🙂

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.

News about Akregator

As you know I decided to fix and improve Akregator for the next release (16.04 in april).

So this week I continued to improve QtWebKit support.

I readded:

  • Adblock support (We can add configure it in akregator config dialog)
  • Save image to disk
  • Adblock specific element in page.

I created a new Grantlee theme. The old theme dated before kde4…

During this work to create new theme I implemented “actions”. The actions is useful when we use a combined view. We can’t change status of article (for example it’s impossible to mark as read/important/unread, it’s static).

Now we can change status or delete article directly. It’s very useful. (see screenshot below akregator-newactions

Others changes:

  • Add action on tabbar (close all tab/close specific tab etc.)
  • Add radio button for view type (so now we know which type of view we use)
  • Clean up searchbar, we have filter actions directly in lineedit. akregator-searchline


I will try to close a lot of bug before next release.

I hope that you will be happy with new version.



Once upon a time a program named Akregator.

It was born in 2004.

But it didn’t evolute during 6-7 years. It was a bad thing for an kdepim application.

Long time ago I worked on akregator2 (a akregator based on akonadi) but it was never released and there is no future for it.

So for the next release (16.04) I decided to work on. (It needs some love)

The first problem was that it used khtml as primary render web engine, it’s a very obsolete engine. (Ok if you installed kdewebkitpart it was able to use qtwebkit, but it’s not all the time).

So I decide to port to QtWebKit directy.

First impression: it’s speed ! (and there is less crash).

Second step I moved all generated html code (which display info about rss) to grantlee, so now it’s more easy to refresh html code.

Next step is to clean up code, and add new features (I have some ideas, and has some idea too)

So I hope to finish all the clean up for 16.04.

I hope that you will happy to use it and you will report bug about it.

Split kdepim and kdepim-addons

Last week after some months I finally split lib from kdepim.


The main reason is that I wanted to make life easy for new developers.

Until now when we wanted to develop an extension for kmail/kaddressbook or other kdepim application it was necessary to build all kdepim.

Now we can create plugins outside of kdepim or in new kdepim-addons repository (Which was created last week too).

Another reason is that these libraries can be used by kontact-quick and by applications as Zanshin (which duplicated libkdepim).


I didn’t do for 15.12 but for 16.04. So I have time to fix all problems.


All split packages are in kde/pim repository


I created this repository for putting all kdepim plugins.

So we can found here:

– messageviewer plugins => header style plugins and messageviewer plugins (create todo etc.)

– pimcommon plugins => customtools plugins as shorturl and translator plugin

– kmail plugins => antispam/antivirus plugins

– kaddressbook plugins => merge contact/search duplicate contacts etc.

So now you can develop more plugins without compile all kdepim.

I will continue to convert features as plugins so we can reduce kdepim code base. And it’s more easy to disable a broken code when it’s a plugin.


I want to create plugins for korganizer too (I will add plugin support).

I would like to create plugin which uses some different language as c++ but I need to investigate how to create it 🙂


Lorsque l’on linke des programmes on s’appuie sur des librairies statiques.

Le problème c’est que l’on peut en ajouter plein lors de la compilation et même si aucun symbole n’est utilisé on va charger cette lib au démarrage de l’application.

Cela va ralentir le démarrage de l’application.

On a plusieurs méthode pour réduire cela:

  1. Retirer chaque lib de la liste des librairies à utiliser et voir si ça linke (long et fastidieux)
  2. Utiliser une application dédiée pour cela => elf-dissector

Elf-dissector est une application développé par Volker Krause (kdepim dev + Qt Dev + KDAB dev + …. 🙂 ) donc pas un inconnu 🙂

Ou trouver Elf-dissector ?

Dans le git de KDE :

“git clone git://”


Il nécessite libelf-devel/binutils/libdwarf-devel/gnuplot

Une fois cela installé il y a plus qu’à faire mkdir build && cd build && cmake -D<….> ../ && make install

C’est vraiment tout simple.


exemple: elf-dissector /opt/kde5/lib64/

C’est une application qui va vous permettre de voir quelles libs sont utilisées et ainsi voir si elles sont nécessaires ou non.

Il y a  6 onglets:

  • Elf structure: nous fournit la structure de la librairie (on peut voir le point d’entrée etc.
  • Size Tree Map permet de voir l’organization dans la librairie
  • Dependancy c’est vraiment l’onglet le plus utile il permet de voir les différentes librairies utilisées et voir le nombre de symboles utilisés dans chaque lib. On peut voir cette qui sont chargées mais qui ne sont pas utile. Si l’on clique sur un item on peut voir les symboles utilisées et donc ceux qu’on doit supprimer si l’on veut plus avoir une dépendance sur telle ou telle lib.
  • Issue permet de voir les erreurs dans la librairie ça prend énormément de ressources donc à manier avec parcimonie

Après vous avez plus qu’à réduire le nombre de bibliothèques utilisées pour votre application.

Attention les dépendances peuvent aussi venir de dépendances indirectes donc difficile des fois à faire les ménages.

Mais cette application nous a permis de réduire le temps de chargement de KMail de 1.3 secondes à 0.6 seconde donc vraiment utile.

Scan-build (clang static analyser)

Clang fournit dans sa suite divers plugins et aussi un analyser statique de code.

Il va simplement analyser le code compilé par clang et il va en faire un rapport en sortie.

Donc tout code non compilé par Clang ne sera pas analysé forcément. Genre il ne va pas aller chercher du code

ou il y a un  #ifdef OPTION par exemple si on n’a pas définit OPTION lors de la compilation.

Comment l’utiliser?

Très simple:

Pour un programme compilé genre kdepim:

mkdir build && cd build && CXX=clang++ CC=clang scan-build -k cmake -DCMAKE_BUILD_TYPE=Debug ../
scan-build -k -o results make

Vous laissez builder et vous aurez le résultat dans le répertoire results sous forme de fichier html.

Attention il peut générer des faux positifs on ne peut pas corriger sans se poser des questions mais ça donne de très bonnes informations sur les erreurs possibles dans le code.

Je vous laisse lire les autres options sur le site officiel