It’s now almost one year since I started my job at BlueSystem to work full time on KDE software. It’s a perfect time to look back and do some retrospection as well as trying to look into the future.

Of course my focus of work was on KWin, but especially over the last months I worked all over the KDE workspaces. Overall we have achieved a great result. KWin is running in near production-ready quality after the port to Qt 5 and the Plasma workspaces are also in a very good shape already. I tend to mentially compare the experience with the state of Plasma 1 six years ago which was just a few weeks before the first release. We are in a better state and there is still lots of time till we will do our Plasma 2 release.

Without the possibility to work full time on KWin we would not yet have a ready port and I fear the quality would have to suffer. There were many issues which just needed lots of time to break through. Sometimes I had the feeling that I run all day long with the head against a wall just to end up in front of the next wall once I broke through. Luckily such problems are behind us and I’m also kind of proud to have solved those problems.

But not everything this year had been fun. There was one event which seriously affected my work in a negative way. It demotivated me, I needed to spend time on it, it made me spent time on useless issues instead of the important porting. I was attacked and insulted for my opinion – an experience I had never made before and I don’t want to make. Of course it affected me personally and I can see the impact of it. In retrospection it is clear that I nearly got burnt by it and that it affected the way how I worked in the free software ecosystem. I notice that I don’t have any interest in collaboration with other projects any more, that I feel attacked whenever someone disagrees with me on a technical level, I am answering questions in a short and blunt way with tendency to arrogance. I try to avoid discussions, stopped caring for bug reports and are lacking on code reviews. To a certain degree I tried to be on my small island where I can just hack and ignore everything else.

I am wondering how I would have taken the whole situation if I were just a spare time developer. Maybe it would not have affected me at all because the pure thought that I am supposed to add support in my spare time would have been even more ridiculous as it is. Maybe I would not have had the time to do an analysis for the Kubuntu team as I did which then would not have resulted in me getting attacked for it. On the other hand if the attacks and insults would have also happened if I were a spare time developer I don’t think I would still be a KDE developer. For a hobby I would not have endured that.

One of the conclusions is that if it would ever happen that someone submits a patch for Mir support in KWin, I would immediately step down as maintainer. After what happened I am no longer in a position to judge that imperial and objective. I would either accept the patch out of appeasement or reject it due to what has happened. In any way I would not be in a position where I can be sure to do the right decision for the KDE community. Even on a technical level I would not be sure whether I would be able to review it. Being nitpicky about small issues can be done subconsciously and also moving around code just to prove the point is easily done.

Please do not read this as a threat to block any patches as there’s more into it. I do not expect that the area of conflict will go away. I expect that the issue will come up again and again and I expect that those lobbying us will continue to do so. The next time will probably be the preparation for 14.10 where I’m quite sure that we (and probably also GNOME) will be attacked again for our decision. As I explained above this is affecting me and it’s something I do not want. The logical consequence is that I will have to reduce my involvement in KWin and the kde-workspaces and focus on other areas. After having worked for six years on KWin it might anyway be a good point to look for new challenges, especially given that I decided years ago to re focus once the Wayland port is done.

Of course Wayland will be the big item for 2014. It’s one of our internal aims for the next few months and given that I had focused mostly on porting of all kind of workspace applications I’m looking forward to work on it again. Given that the number of applications ported to Qt 5 is increasing each day it will also be a nice thing to work on with hopefully soon switching to a dog-foodable environment having real-world Wayland enabled applications and not just the Wayland demo apps.

Laptop and BII window decorations want to be ported to KWin/5

At the moment the window decorations Laptop and BII are disabled from build in kde-workspace master branch. From the KWin development team side these two decorations had been unmaintained for a long time and this means I will not do the port and I don’t expect anyone else from the core team will port them.

This means it depends on YOU dear reader to make sure that those two decorations are also available in the next release. So if you are using one of the decorations and are able to program in C++ please step up and port them (also maintaining would be awesome).

If nothing happens till let’s say end of January I will git rm those two decorations.

Quick Window Switchers in KWin 5

One of the oldest usages of QtQuick in KWin are the Window Switchers. During the design it was aimed for having them Plasma-styled just like the previous implementation. This was not as easy as one could hope, because back then we couldn’t use the Dialog component provided by PlasmaCore. So all the various Switcher styles implemented the Plasma styling themselves and the C++ side did some additional adjustments like guessing the blur region. As the Plasma theme recognized that the blur effect is active the FrameSvg used as a background was rendered in the blur-available translucency state. To have it readable it needs to be blurred.

For this we would the correct blur mask of the FrameSvg but that’s not available from the Qml bindings. The hack we went for was to just assume in the C++ side that the switcher is Plasma styled, created another FrameSvg of same size and extracted the blur mask from that. Sounds fragile, doesn’t it?

And of course there came the day when that broke. About a year ago we noticed that the shadow doesn’t work any more and we needed to bring in some more fixes to make that work. If we would have used a PlasmaCore Dialog this would not have been an issue at all.

Now after the Qt 5 port the blur and shadow was once again broken and once again I was about to start fixing it. But nowadays we use the Plasma Dialog in e.g. declarative KWin scripts (the desktop change OSD being a prominent example). So I took a step back and thought about instead of fixing the fragile code to re-think it and make it possible to use the Plasma Dialog or in general QtQuick Windows from inside the Qml code.

Given that this required to adjust all switchers anyway I decided to go a step further and also improve the API a little bit. So far all the important data was exposed as context properties. I’m not a huge fan of context properties as it’s kind of magic. Instead there is now a dedicated switcher item available, which is just a QObject exposing a few properties:

import org.kde.kwin 2.0 as KWin

KWin.Switcher {
    property QAbstractItemModel *model // The model with either the windows or the virtual desktops
    property QRect screenGeometry // The geometry of the active screen (as KWin thinks of active)
    property bool visible // Whether the switcher is currently visible or not, a Window should follow this
    property bool allDesktops // Whether the switcher includes windows from all desktops or only the current one
    property int currentIndex // The index of the selected window - this is controlled from KWin side

The model provides the following roles for Window Switchers:

  • caption – The caption of the window
  • desktopName – The name of the virtual desktop the window is on
  • minimized – Boolean whether the window is minimized or not
  • windowId – Window system specific identifier
  • closeable – Boolean whether the window can be closed
  • icon – QIcon containing the window’s icon

With that we can design a very simple thumbnails switcher:

import QtQuick 2.1
import org.kde.kwin 2.0 as KWin
import QtQuick.Window 2.1
KWin.Switcher {
    id: switcher
    currentIndex: listView.currentIndex
    Window {
        id: window
        flags: Qt.X11BypassWindowManagerHint // important, without it won't work
        visible: switcher.visible
        color: "white"
        x: switcher.screenGeometry.x + switcher.screenGeometry.width / 2 - window.width / 2
        y: switcher.screenGeometry.y + switcher.screenGeometry.height / 2 - window.height / 2
        width: switcher.screenGeometry.width - 100 // keep 50 px space to each side
        height: 200 * (switcher.screenGeometry.width/switcher.screenGeometry.height) + 20
        ListView {
            id: listView
            orientation: ListView.Horizontal
            model: switcher.model
            spacing: 10
            anchors.fill: parent
            anchors.leftMargin: 10
            anchors.rightMargin: 10
            delegate: KWin.ThumbnailItem {
                width: 200
                height: width * (switcher.screenGeometry.width/switcher.screenGeometry.height)
                wId: windowId
                brightness: ListView.isCurrentItem ? 1.0 : 0.5
                saturation: brightness
                MouseArea {
                    anchors.fill: parent
                    onClicked: {
                        listView.currentIndex = index;
            Connections {
                target: switcher
                onCurrentIndexChanged: {
                    // currentIndex is updated from KWin side - need to keep in sync
                    listView.currentIndex = switcher.currentIndex;

I wrote this code directly in the blog post without any testing at all (hey it found one bug in KWin and two in the systemsetting previewer. I should do such stuff more often 😉 ). So let’s see how it looks like:

Aus TabBox

Not a bad result for 50 lines of code. As one can also see from the code it does not do any Plasma styling at all any more. Which is a nice side-effect for the usage of KWin outside the Plasma workspaces. The changes to get Plasma styling is not difficult either. Just use PlasmaCore.Dialog instead of the Window and that’s it.

Firefox KDE integration in Debian Testing

One of the features I dislike about Firefox is the lack of any integration with the environment it is running in. It doesn’t recognize the correct applications to open files and presents the IMHO unusable GTK file dialog. The file dialog is a real problem to me. I often have to download patches from reviewboard and my KDE file dialog has all the shortcuts to get into the source directories.

Thanks to the openSUSE people there are patches to get a working KDE integration. But those are not upstream and not all distributions includes them. So if you are not using openSUSE chances are that you don’t get those goodies. Thanks to Blue Systems there is a PPA for Kubuntu: firefox-kde.

Even better: this PPA is also working on Debian Testing. But one needs to use the “raring” repository and not “saucy” (unmet dependencies). The normal warnings about adding additional repositories to your system apply. Don’t blame me if it breaks your system. Just add the following to your sources.list:

deb raring main 
deb-src raring main 

I highly recommend to apt-pin the “raring” release, so that it doesn’t update your packages from this repository:

Package: *
Pin: release a=raring      
Pin-Priority: -2

Now update the sources and install firefox and firefox-kde-support. On Debian the package is called iceweasel and firefox can be installed next to it: the files do not conflict. Close any running iceweasel instance and start Firefox (no longer iceweasel).

Aus 2013-12-01

Additional gimmicks: newer version as it’s based on Ubuntu’s Firefox and appmenu integration.