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 bugs.kde.org 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.

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

Why?

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).

When?

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

Where?

All split packages are in kde/pim repository

kdepim-addons

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.

Future:

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://anongit.kde.org/elf-dissector”

Compilation:

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.

Utilisation:

exemple: elf-dissector /opt/kde5/lib64/libKF5MailCommon.so.5

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.

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 http://clang-analyzer.llvm.org/scan-build.html

Les développeurs KDE ne sont pas en reste pour ce qui est des outils pour aider à améliorer la qualité du code.

Sérgio Martins a développé “Clazy” un outils qui utilise Clang pour rechercher et avertir de certaines améliorations à faire dans votre code. Certains de ces plugins peuvent directement modifier le code source.

Comment le builder ?

Déjà récupérer le code source git clone git://anongit.kde.org/clazy

Il faut clang-devel >= 3.6

Ensuite il faut le builder et cela contre clang.

mkdir build && cd build && cmake  -DCMAKE_CXX_COMPILER=/usr/bin/clang++ -DCMAKE_C_COMPILER=/usr/bin/clang -DCMAKE_INSTALL_PREFIX=<path> …/ && make install

Maintenant il faut s’assurer que <path>/lib64/ est dans votre LD_LIBRARY_PATH sinon ça ne marchera pas.

Dès que tout cela est fait vous pouvez l’essayer sur un projet.

Comment l’utiliser ?

Il faut export la variable CXX

export CXX=”clazy”

Ensuite il faut dire ce que vous voulez évaluer.

Si vous voulez avoir tous les warning reportés par clazy, il suffit d’exporter une deuxième variable:

export CLAZY_CHECKS=all_checks

Après il faut reconfigurer le build sur votre projet

cmake -DCMAKE_INSTALL_PREFIX=<path> ../

et là vous aller pouvoir voir tous les variables et les infos résultant.

Les divers plugins:

  • bogus-dynamic-cast
  • foreacher
  • global-const-char-pointer
  • inefficient-qlist
  • qstring-uneeded-heap-allocations
  • qstring-arg
  • qstring-ref
  • function-args-by-ref
  • qmap-with-key-pointer
  • non-pod-global-static
  • reserve-candidates
  • variant-sanitizer
  • virtual-call-ctor
  • missing-typeinfo
  • implicit-casts
  • old-style-connect
  • detaching-temporary
  • assert-with-side-effects
  • qgetenv

Comment faire les fixes directement dans le code?

C’est très simple :) Il suffit de le dire à Clazy en exportant la variable CLAZY_FIXIT

Par exemple:

export CLAZY_FIXIT=”fix-missing-qstringref”

Il y a que quelques plugins qui permettent la modification directe.

export CLAZY_FIXIT=”fix-old-style-connects” (change le style de connexion signal/slots (la nouvelle API qui est arrivée avec Qt5)
export CLAZY_FIXIT=”fix-missing-qstringref” (ça adapte le code pour utiliser const + ref lorsque c’est possible)
export CLAZY_FIXIT=”fix-fromCharPtrAllocations” (les 3 autres c’est pour réduire l’allocation lors de l’utilisation des QString)
export CLAZY_FIXIT=”fix-qlatin1string-allocations”
export CLAZY_FIXIT=”fix-fromLatin1_fromUtf8-allocations”

CLAZY_FIXIT ne permet pas de faire tout ensemble c’est un plugin par compilation ce qui est un peu logique car changer un fichier en court de route et remodifier encore derrière serait très risqué)

Mais pour fixer kde j’ai créé un script. Vous pouvez l’utiliser clazy-compile

il suffit de le renommer en .sh et le l’exécuter il fait tout pour vous.

Le futur ?

Ben il y a toujours des vérifications de code à faire et des optimisations donc ça va continuer. Mais j’en sais pas plus :)