kdebugsettings 1.0

Before to increase version to 1.0 I moved it from kdereview to kdeutils.

I added new features of course 🙂

Now you can import/export settings directly.

You can create a category file and it will load in kdebugsettings.

It’s very useful for big project as kdepim for example when I add a new logging categories for each module, but I don’t want to wait a new release.

So you need to create a “.categories” file and install it as “install( FILES kdepim.categories DESTINATION ${KDE_INSTALL_CONFDIR} )”


No idea 🙂 If you have so wishlist send me a bug 🙂

Embedded QML in qrc file

KDAB works on a lot of projects based on qml.
But sometime for specific applications it’s not safe to store directly qml file on file system.
As you know the QML files are plain text files.

For example if an user can have access to qml files he can change the logic of the application.
This is not critical for a application as  “Clock” but it can be critical in other domains.

So there is two methods to avoid it:

  • Using the Qt Resource for embedding the QML files (This blog will explain how to do).
  • Using the qtquickcompiler to generate a precompiled QML file (But a commercial license is needed)

The Qt Resource system allows to store a lot of data/binary files in executable directly.
Data can be an icon, a translation file, etc. and of course a QML file.

This blog will explain how to use it in a QML plugins implemented based on a QMLExtensionPlugins class.

For a standard application which uses some QML files this is very easy. We put them in a qrc file and we can access to it directly with a line as “view.setSource(QUrl(QStringLiteral(“qrc:/plugins.qml”)));”

We will see how to do it on a example based on qmlextensionplugins.

We adapted a qt qmlextensionplugins example (It’s the Clock example that you can find in qt source code) to create an little application.
Source code can be download here

It will display a clock.
The pro files were adapted to allow to install apps in “install” directory.
(qmake && make && make install).

When you look at install folder you can see all these files.


=> As you see the QML files are stored on filesystem.

Now what we need to change for using Qt Resource ?

We will create a Qt Resouce file which will embed all qml files and icons.

<qresource prefix=”/clock”>

There is not a specific prefix.
And you just need to adapt qmldir for using a specific QtResource path (use qrc:///<path>)

module TimeExample
Clock 1.0 qrc:///clock/Clock.qml
plugin qmlqtimeexampleplugin

Of course the file qmldir can’t be stored in Qt Resource file otherwise  the application will not be able to  find plugin.

As you see now the list of files in install directory is limited to:


(of course I stored plugins.qml in another qrc file).

So the application is more safe now.

You can get source code here

KDebugSettings (0.3)

I improved kdebugsettings (and increased version to 0.3).

What’s new:

  • I added an Apply button so now we can test rules directly
  • We can customize kdeapplication rules, before we could just enable/disable them, now you can specify that you want to show just Debug/Critical/All (as for custom rules)
  • There is a new tab which shows rules which are stored in QT_LOGGING_RULES environment variable.
  • I added a warning when a rules starts by “*” which can override all others rules.
  • I added an Help button which show Qt qloggingcategory page


I will add a button to export/import rules.

I will ask to move it in kdereview. I think that it can move in official package.


Warning about "*" rules

Customize kdeapplication rules

Customize rule



Some weeks ago I spoke with David how to configure what debug to show in qt5 (now it uses qloggingcategory)

In kde4 time we had kdebugdialog. It allowed us to define some debug areas.

But we are not able to extend it because it was in kdelibs4support module and it was kdebug specific.

Qt5 doesn’t provide application to do it.


So I decided to create a new application named “kdebugsettings” (c) David 🙂

This application worked as old kdebugdialog, we have a file which defines categories.

This file is named kde.categories.

I added debug area that I found in source code. More areas will add in the future.

It will allow to generate qCDebug rule.

In kdebugsettings we have 2 tabs, one for kde applications which are defined in kde.categories and another one which allows to define custom rules (if you want to show warning/debug/all, enable/disable it).

Where to find it ?

It is stored in projects.kde.org, in playground/util module.

You can test it and report bug/feature etc.


I hope for 15.08 to release it.


Last week I decided to evaluate “Ninja”.

What is it ?

It’s a build system developed by Chrome for Chrome. Evan Martin Developed it during his work.

He wanted to create a fast build system. It was a success 🙂

How to use it ?

Easy you need to create a file named Ninja.build which defines all dependancy as a Makefile.

But it’s not a problem because CMake is able to generate it for you.

So for KDE it’s not a problem as we use CMake to generate projects.

So now the command line:

“cmake -GNinja ../”

Too bad we can’t override default cmake generator. So I created a alias on my computer to avoid to write each time a big command line:

Add “alias cmninja=’cmake -GNinja'” in .alias

After that you call it you will have a “ninja.build” in build directory.

Now for launching the build it it’s very easy: write “ninja”

make <-> Ninja commands:

Ninja has same commands as Make.

make clean <-> ninja -t clean
make -j8   <-> ninja -j8
make install <-> ninja install
make -k <-> ninja -k[X] (it will stop after X failed)

Pro/Cons ?


  • Faster as Make when we build from scratch
  • Less verbose as make
  • Very fast when we build and there is no files which changed (the time can be divided by 3 some time). So very fast when we rebuild all kde 🙂
  • Ninja will detect the amount of CPUs and use them all. (Not necessary to use ninja -j<X>)


  • We don’t have color output.
  • We can’t build in subdirectory. For example if I build kdepim and I hack kmail, I can go to kmail subdirectory. I very bad for it.
  • qmake doesn’t generate ninja.build so we can’t use in qmake project.

Can I use in kdesrc-build?

Yes you can ! I use it.

Correction: We can use it in top-level.

This morning I fixed kf5-frameworks-build-include which forced build system.

So now you can add “custom-build-command ninja” in global settings of kdesrc-buildrc

cmake-options -GNinja -DCMAKE_BUILD_TYPE:STRING=debug -DKDE4_BUILD_TESTS=true

(just adds “-GNinja” to your current cmake-options)

So how I use it?

I use it for building all plasma5/kf5, it’s very fast to build. So I am happy.

For kdepim I still use make as I want to build in subdirectory.

More information:

You can have more information here: http://martine.github.io/ninja/manual.html

Comment avoir le systray sous plasma5

Pendant qq semaines j’ai pas compris pourquoi j’avais pas de systray.

C’était ennuyeux pour konversation ou KMail.

Eike Hein m’a donné la solution: libdbusmenu-qt5 et bien sur qt5.4 et sni-qt4 🙂

Oui ça fait beaucoup mais sans cela ça marche pas et c’était très ennuyeux.

Voilà pour ceux qui cherchaient au cas ou.

Plasma5 et juste kmail kde4

Depuis quelques semaines j’ai fait la migration à Plasma5.

La seule application que je peux pas migrer encore est kmail (et applications associées).

Alors je pourrais utiliser les versions fournies par ma distro mais bon je suis dev donc j’ai besoin de la version ‘master’ 🙂

Donc c’est possible de faire cohabiter les 2 environnements dans le même répertoire, mais ça demande quelques changements.

Alors ma méthode:

-> builder tout kf5 sauf kdepim/akonadi (kdesrcbuild peut faire cela tout seul)

-> builder tout kde4 donc kdelibs/akonadi/kdepim* (bien sur pas le reste de kde4 qui servirait à rien et conflicterait).

Et ça marche bien 🙂

Alors comment je fais:

j’ai créé un répertoire:

“/kde5/source/kde5-4” (le nom importe peu 🙂 )

dedans j’ai mis un   kdesrc-buildrc ça a la configuration standard. (à adapter pour votre machine bien sur)

mais dans “extragear/utils/kdesrc-build/kf5-qt5-build-include”  j’ai commenté le build de  kdepim “#include kf5-kdepim-build-include”

une fois cela buildé on peut builder kde4

j’ai créé un sous répertoire “/kde5/source/kde5-4/kde4”

et là de même un kdesrc-buildrc-kde4 qui construit que ce qu’il faut

Et après un ptit bout de temps vous pouvez avoir un plasma5 et un kmail4

Et tout marche nickel:)

Une fois que vous avez cela pour mettre à jour il y a quelques petites choses à faire.

Le rebuild de plasma5 va pas marcher car il trouve les includes de kde4

Donc avant chaque build je fais:

“cd /opt/kde4-5” (on répertoire ou se trouve le build)

mv include/*.h  /include/old/
mv kactivites/ kactivites-old
mv kio/ kio-old
mv plasma plasma-old

je build plasma5

et après je vais l’inverse:

mv include/old/*.h  /include/
mv kactivites-old/ kactivites
mv kio-old/ kio
mv plasma-old plasma

et je rebuild kde4

voilà et tout marche sur des roulettes 🙂

J’espère que ça aidera ceux qui veulent faire comme moi

Bon WE.

KDEGames kf5

In December I blogged about porting of kdegames to kf5.

My objective was to release some games for the ‘15.04’.

So I worked harder to make it possible.

You can see status here : https://techbase.kde.org/Projects/Games/kdegame_apps_porting_kf5_status

So the plan now is to merge some application in master.

This WE we will merge libkdegames and the game names Bovo.

After that we will merge some applications when it’s possible (A game mustn’t have kdelibs4support, must have migration settings done, etc.) each 3 days until 15.04 freeze (in 4 weeks).

So we need YOU !

We need some testers to help us to make as bug free as possible.

Bonne année 2015

Alors bonne année à tout le monde!!!

Je souhaite que KDE soit de plus en plus utilisé sur le bureau 🙂

Bon cette année devrait être l’année KF5, de plus en plus d’applications sont portées.

Donc je pense que d’ici 6 mois les distros l’utiliseront par défaut.

2015 devrait être une bonne année!

kdepim 4.14 + unittest

As you saw I continue to work on 4.14 branch, in parallel I work on KF5 porting.

Why do I continue to work on 4.14 ?

Because KF5 kdepim version will not arrive before that AkonadiNext will be stable, so it will take time. AkonadiNext is writing from scratch.

I don’t know if you remember but during porting to akonadi, kdepim 4.4 was not improving during 2 years, no bug fixing, nothing. It was a very bad idea.

So I decided to continue to fix 4.14, until we release KF5.

What do I do in 4.14 ?

I continue to fix bug. And there is still a lot of bugs 🙂

I try to make it stable.

During this period I try to write a lot of unit-test on this branch.

Why do I write unit test ?

Because there is not unit test on kdepim 🙂 It’s a good reason.

But there is a second reason, as I port kdepim to KF5 and it’s not stable to use it, I can’t know if all works fine. So I create unit test, I verify that it works on 4.14 and after that I just need to run unit test on KF5 to be sure that it works fine on KF5 too.

What do I do when I add a new feature in KF5 ?

Now each new feature that I add, or feature will add in kdepim will have a unit test.

So in KMail or in each lib/apps that I maintain in kdepim, I will not accept new feature if there is not unit-test, because it’s very useful and I don’t want to write them after 🙂

It’s a pain when we need to write unit test on a code that we didn’t write.

And sometime code is not adapted to create unit test so it’s necessary to rewrite it. (I rewrote some code in 4.14 to allow to create some unit test).

It’s more easy to create unit test when we write feature that write them after.