Next step: running

Last week I reported that KWin compiles and links against Qt 5 and KF 5. This week I’m glad to report that I got KWin also to run. The biggest issue was a PEBKAC – if you try to run anything build against frameworks make sure to not have KDE 4 libraries in your LD_LIBRARY_PATH.

Aus KWin

Before you are tempted to run KWin next in the new Project Neon setup a word of warning: it will dead lock. The current code base I use for testing depends on not yet upstreamed changes in frameworks and Qt. Obviously I have not yet pushed the KWin code needing these library adjustments but without them KWin will hit a dead lock – more to that explained later on.

Project Neon has been a huge help over the last days. Harald reported again and again build issues which we were not able to detect on our system because we also have Qt 4 installed. One example was a file being included which does not exist anymore in KF 5. As it was installed in /usr/include I was not able to detect such a problem, but with a clean setup like Project Neon it becomes immediately obvious.

So what is already working in KWin on 5? The most obviously visible one is the compositor. This doesn’t surprise me much, I didn’t expect any problems there. So far I have mostly tested the XRender compositor as I’m currently mostly working with Xephyr which only provides llvmpipe OpenGL and I rather spent my CPU cycles on compiling than drawing triangles. Since yesterday I have also Oxygen shadows working again which I had initially disabled as it needed XCB porting. But it just looked too strange without them, so I had to enable it 😉 I think Hugo ported Shadows in Oxygen for the same reason.

Related to the compositor is the effect system and our effects. This was rather surprising for me: they just worked out of the box. The only major problem is that global shortcuts are not yet supported so I have problems triggering them. For some effects I solved this problem by just adding a DBus interface – might be an idea to keep this; some users might appreciate it. Only the scripted effects were not loaded because I did one mistake during the initial porting – this is fixed since today as you can see by the dialog parent effect being applied in the screen shot above.

Also window decorations work, though there is still quite some work to be done. For example the QML based Aurorae does not like to work which is the reason why I ported Oxygen over. It’s overall nice to see that it works, but it seems to be only working with compositing enabled. Not so surprising as this hits areas which changed a lot inside Qt.

The window manager seems also to be working, though obviously I have not tested all features and are using only a minimal sub set of the available functionality. Due to missing global shortcuts support it’s difficult to test all features and due to missing port of the configuration interfaces I cannot even adjust the configuration (well I could just edit the config file, but…).

Nevertheless there are still quite some issues which need investigation and fixing before I can start to consider using KWin 5 in production. The biggest problem at the moment is that all windows present at startup get unmapped and are kind of lost to the window manager. So far I have not yet been able to figure out why this is happening. That is for example a show stopper if you would want to use it in a neon setup. (Update: This issue is fixed as of 3bddd1100aa)

The biggest change for KWin is the port of the event filter from XLib to XCB and this is still causing some headaches to me. With XLib one was able to look into the future by inspecting the XEvent queue or to the extreme wait till a specific event has arrived. With XCB the event queue doesn’t allow to be inspected which makes porting properly a non-trivial task. KWin was using this functionality at three places (at least that’s what I found so far). During move/resize operations we only process the last mouse motion event currently in the event queue to limit the resizes. This functionality should be possible to emulate with a more async event handling approach. The second usage is that we do not deactivate a window on focus out event if there is also a focus in event following. The documentation says this is to prevent flickering. In a composited world it doesn’t really matter as the compositor should prevent the flicker, but also here a more async approach should be able to handle it.

The big problem though is the third usage: updating the current xTime. KWin needs to have the most recent X time to be able to properly compare timestamps. This is done by changing a property and waiting for the event which contains the timestamp. In addition KWin does some more tricks like looking at the first event in the queue containing a timestamp, to get it really correct. Now with XCB event queue not being available to us this is a sever issue as without this functionality KWin doesn’t function properly. While looking at how to solve the problem I discovered that the XCB QPA internally uses a method providing this functionality of getting a current timestamp. Not with all the bells and whistles as we used to have in KWin, but good enough for a start. So my solution at the moment is to have my local Qt copy to make this function available and by that solve the problem. That’s the change I talked about in the beginning of this blog post.

As you can see there has been quite some progress and I hope to get KWin in a dogfoodable state quite soon. And that’s something where you can help. There are many easy tasks available which just need you to be able to compile KWin and with Project Neon this just became easier. So drop by the Trello board and claim your task. This week I was already able to push one first time KDE commit with a small cleanup for our code base 🙂 So who wants to be next?

9 Replies to “Next step: running”

  1. Sorry to be really offtopic but i find it kinda hard to get some doc/info about KF5 (if you don’t have the answers, maybe you could help me get in touch with some KF5 developers? I’m even willing to help write some FAQ blogpost for planetkde/planetqt).

    Let’s say I’m starting to develop a Qt5/QtQuick2 application (targeting mainly desktops and maybe tablets in the future):

    – Will it be possible to incrementally add KF5 support on the C++ side ?
    – On the Qml side, what is the best approach ? Use PlasmaComponents on KDE and QtQuick Controls everwhere else ? Or QtQuick Controls for KDE Desktop and only PlasmaComponents on Plasma Active ?

    1. KDE Frameworks 5 is mostly about modularizing kdelibs. That’s pre QtQuick2 time, as there has not been a release yet I think it’s very premature to think about how to add support. KWin is getting ported, because it’s more difficult than normal applications to port it, we just need more time and because of that it is OK to work against an unstable base.

  2. What benefits will KWin (and KDE for that matter) gain from being ported to QT5 besides QML?

    Considering that KDE is community driven and that porting efforts likely take up a large portion of the developer bandwidth, wouldn’t it be better to just stick with a QT4 base and spend the time on improving the user experience?
    Don’t take this as criticism. I’m just curious 🙂

    1. Qt4 is dead, this is clearly not an option. Apart from that Qt5 contains the QtWayland module which will make it easier to interact with Wayland.

Comments are closed.