Explore KWin’s Source Repository Change over Time

Today I’m happy to present some statistics about KWin’s source repository. The shown graph is HTML5/JavaScript, so I’m not sure whether that works on the planet or in an RSS reader. In case it does nto work you can get to the diagram here – as it’s an iframe it seems to be even bad on my blog. Best just open directly 🙂

What does this graph show?

For each (toplevel) directory in KWin’s source base the source line code is shown for each of our releases of the 4.x series.

How to use the graph?

The graph is interactive. With the checkboxes you can enable/disable the individual directories. With the drop down list you can select which information to show:

  • Total line count
  • Code and Comment
  • Code only
  • Blank only

The graph also provides context information. If you hover over a data point a tooltip is shown with information about the directory at the release. This includes the different counts and a break down per used programming language. The tooltip is not yet perfect and it might be needed that you disable a dataset to better read it.

What is 4.6*1 and 4.6*2?

Shortly after 4.6 got branched we did a coding style change over most of KWin’s source base. Due to that change we lost a few thousand lines of code. As that has not been any change in functionality the graph between 4.6 and 4.7 is incorrect. Therefore 4.6*1 is included as the commit prior to the coding style change and 4.6*2 as the commit of the coding style change.



With main the toplevel directory is meant. It contains the window manager and the compositor. Over time some features got split out into sub-directories. E.g. tabbox in 4.4, tiling in 4.8.


In 4.7 the lib directory got split into two dedicated directories called libkdecoration and libkwineffects.


For historical reasons the directory “clients” contains our window decorations such as Oxygen. Between 4.1 and 4.4 KWin contained the window decoration Oxygen twice. There was also a fork called Ozone with slightly different settings. Overall that meant that the code got duplicated. In 4.4 this situation was resolved by making another Oxygen fork called Nitrogen the new Oxygen. Also the theme engine Aurorae got introduced which explains the strong increase in size between 4.3 and 4.4. The strong drop in 4.6 is explained by moving some legacy decorations out of KWin.


Kcmkwin contains all the config modules of KWin. Changes in source code are mostly related to new KCMs being introduced. 4.3 got a config module for screen edges, 4.4 a config module for Alt+Tab, etc. The only change in that pattern is that in 4.10 we introduced .ui files for our legacy KCMs which replaced C++ by more verbose XML code.


Not much to say. I would recommend to have a look at this dataset without the other ones. One can clearly see how we got more effects till around 4.6 and then it started to stagnate. The strong drop between 4.8 and 4.9 is caused by moving some effects from C++ to JavaScript. The increase in 4.10 is caused by migrating settings to KConfigXT which introduced lots of XML.


TabBox is the Alt+Tab implementation for switching between windows and desktops. It got split out with a new implementation in 4.4 and had been mostly untouched till 4.9 where large parts got rewritten in QML.

Scripting and Scripts

Scripting is KWin’s scripting engine for KWin Scripts and scripted KWin Effects. Scripts contains a few scripts we include to replace features from KWin core.

Tiling and tilinglayouts

The now removed tiling implementation.


Mostly KConfig update scripts


The window killer (ctrl+esc)

What’s missing?

Unit tests

Unit tests are not considered as they tend to be rather large in code without adding any functionality.


The tool to process the source base (more in the next section) is not able to parse glsl files. But it’s not much wc -l tells me 87 lines for the main directory containing the basic compositor shaders.

Plain Text Files

All the desktop files are missing. We have quite a lot but they are not really interesting as they are mostly containing translations.


The data is generated using the tool cloc in version 1.56 as provided by the Debian (Wheezy) package cloc in package version 1.56-1.

For each of the versions (git tags) cloc was run in the git checkout (clean checkout just for getting the stats) once in each of the specified directories. The result was written into an xml file in a directory specifying the version.

For reference the shell script used to automate the process:

SUBDIRS="clients data effects kcmkwin killer lib libkdecorations libkwineffects opengltest scripting scripts tabbox tools tiling tilinglayouts"

for i in `ls $VERSIONS`; do
  git checkout $i
  cloc --force-lang=XML,ui --force-lang=XML,kcfg --exclude-dir=clients,data,effects,kcmkwin,killer,lib,libkdecorations,libkwineffects,opengltest,scripting,scripts,tabbox,test,tools,tiling,tilinglayouts --xml --report-file=$VERSIONS/$i/main.xml .
  for j in $SUBDIRS; do
    cloc --force-lang=XML,ui --force-lang=XML,kcfg --xml --exclude-dir=test --report-file=$VERSIONS/$i/$j.xml $j

This generated quite some xml files which were processed with a hand written tool. It reads in all the xml files, processes the information and prints out a javascript section to stdout which can be used as input for the jQuery flot graph library. Anything else in HTML and JavaScript can easily be seen by looking at the code 🙂 The order of the datasets got manually re-ordered to make more sense. E.g. having the three lib directories grouped together.

If there are more questions to the methodology: please ask and I will provide the information and in case something is missing extend the section.

5 Replies to “Explore KWin’s Source Repository Change over Time”

  1. “I’m not sure whether that works on the planet or in an RSS reader. In case it does nto work you can get to the diagram here – as it’s an iframe it seems to be even bad on my blog.”

    Yep, doesn’t show up on Planet KDE, and gets horizontally cut off here on the blog (and invisible when JavaScript disabled).

    The best thing in such a case is probably to only include a PNG/JPG thumbnail in the blog post, and make it link to the external page.

  2. The statistics for unit tests could perhaps be used to look for areas that could benefit a lot from getting at least some basic unit tests. I think unit tests add functionality to at least the same extent as comments and blank lines 😉

    1. code coverage is important. The number of line counts is not really. And code coverage data I have in my Jenkins 😉

      1. Could you please post some statistics on the code coverage of the tests, would be really interesting to see.

        1. I don’t have complete stats. I only have stats for the areas covered by unit tests. Those are quite good but how much it really is, I don’t know.

Comments are closed.