Workspace Sprint

The last week I was allowed to spend in Pineda de Mar for the Workspace sprint. As others have already pointed out it was quite a different sprint with not much hacking going on and not so much technical discussions into the details. For this we will have a Tokamak sprint in Randa later this year.

Our sprint was mostly focused on community building and getting everyone on the same knowledge level. The weeks leading to the sprint showed that this was needed and I myself – although being involved in Plasma for quite some time – had to catch up on many things I was not aware of. The sprint helped us to identify for example weak spots in our internal documentation and getting this fixed is now one of the highest priorities.

The games Kevin played with us really helped us to identify where we want to go and what that means for our future development. This will also influence KWin’s development as we finally understand how Activities and Desktops go together and that helps us in KWin to properly focus development effort on it. Over the last cycles we did not really work on activities support in KWin as we were very unsure on how the window manager is involved in the process. This is now much clearer to me – I just need to document it and luckily Aur√©lien already started that process.

Luckily I was able to also get some hacking done. As Mr Gwenview was sitting next to me, I started to add some OpenGL magic to the image viewer. Sometimes I just need to work on a different piece of code and to get away from the daily work on KWin. The result is a much smoother zooming experience. At the moment the feature set is not yet identical to the existing implementation, but it’s on a very promising way. Very pleasing is also that at least on my system it works also well with llvmpipe, which could be a very nice solution for the case that a user does not have a decent OpenGL graphics card. For users who like to experiment, feel free to give a try to graesslin/opengl branch in the gwenview repository.

Overall it was a very nice sprint, but also very exhausting. I’m glad that I have one day to relax before going back to work. And I am really glad to see everyone again at this years Akademy where I will give a talk about KWin scripting.

Please thank the Frankfurt Airport for this blog post. Thanks to needing more than forty minutes to get my luggage from the plane to the belt I missed one train by two minutes (it went > 1h after landing) with the next train only after one hour instead of the normal half hourly service.

Unit Testing a Window Manager

KWin is one of the oldest KDE applications still in active development without having been rewritten from scratch. Development of KWin started in 1999 for KDE 2, but some parts of KWin even date back to KWM from KDE 1 times. The main software design of the Window Manager component hasn’t changed that much since the initial commit – there is a “Workspace” which manages “Clients”.

Personally I find it very interesting to see such old parts of the code and software design. If we think about it we realize that the development started just a few years after the Gang of Four published their book about Design Patterns. Also development-methods like Test-Driven-Development and unit testing got described around that time for the first time.

Given that it is not surprising that when development to KWin started unit tests were not added to the code base. At the time when QtTestLib got introduced KWin had already been in development for six years and not necessarily a code base which could easily be unit tested. Some classes inside KWin had turned into a size which makes it hardly possible to mock the required functionality.

In order to use QtTestLib the port to Qt 4 had been required. At the same time compositing support got added to KWin – an area which mostly depends on visual representation and which is hardly unit testable at all. It is quite understandable that at that time nobody considered it worth the effort to add unit tests to the existing code base.

Also it’s quite difficult to start with unit testing if you have been developing an application for a decade without unit tests. You might not see the need for the tests and in general we can say that adding the first test is the most difficult. For an application like KWin which highly requires interaction with an external application (X-Server) it is quite clear that one might consider it as impossible to unit test KWin at all.

Personally I believe in the usefulness of unit tests especially during bug fixing. So I think that each bug fix should come with a unit test illustrating the problem. Unfortunately there is still a long way to go before establishing such a policy in KWin due to the difficulties in performing unit tests for a window manager.

Nevertheless even KWin has parts which can be unit tested. And recently I added the very first test to KWin. In 4.8 the KConfig Update Script had a small bug which resulted in very rare cases in an incorrectly migrated configuration. When adding the KConfig Update Script for 4.9 I wanted to make sure that all possible upgrade paths are considered and therefore added the very first unit test for the KConfig Update Script.

With that the most important first step is done: the KWin source tree contains a tests directory and now it becomes easier to add further QtTestLib based tests. So when I recently started to refactor some code which can be unit tested I decided to go for adding a unit test together with the new implementation. And I must say it turned very useful – some minor bugs I added, could be easily spotted without any code investigations. Just the way I like it.

Unfortunately unit testing with QtTestLib allows only to test a very small portion of KWin. Anything interacting with the X-Server cannot be tested that way. Many parts require to be a window manager and as the situation is you can only have one window manager running. So a unit test would need to be a window manager and would interfere with the working system – nothing we want from a unit test.

Given that we would have to basically start the full-blown KWin to perform tests which interact with the X-Server. Unit tests are out of scope and only integration tests seem feasible. But in fact running tests against a running KWin cannot work as it would interact with the running system. E.g. how to test that a window is set to keep above if there is a window rule that forces the same window to keep below.

This is a difficult topic to solve. We basically need a dedicated testing framework which starts a (nested) X-Server, starts KWin, performs a test and shuts down both KWin and the X-Server. A framework which is decoupled from the running system.

I’m currently supervising a Bachelor Thesis to evaluate the possibilities of such a framework and to implement a prototype tailored towards the needs of KWin. The current ideas look very promising and are based on KWin’s scripting capabilities by injecting KWin scripts to test certain functionality. I’m looking forward to this implementation as I hope that it will make our life easier – even if it will not be possible to run the tests on a Jenkins installation.

Also I really like the idea of working together with students. We already do that during GSoC, but there are so much more possibilities for FLOSS to work together with academics. Being it Bachelor Thesis or just seminar papers: FLOSS source code is a great area to work together with real world software and not just a demo application as it is so often the case at Universities.