A KDecoration2 update

Before heading into the weekend I thought about writing a small update about the KDecoration2 status. Since my last blog post I started integrating KDecoration2 into KWin. This was partially easier and partially more difficult than anticipated. Especially ripping out the old decoration code is rather complex. There are quite some design differences which make the transition complex and especially values inside KWin core are using enums defined in the decoration API – e.g. the maximized state is kept as a KDecorationDefines::MaximizedMode. This will need further work to move the enums and so at the moment the old decoration library is still compiled although the library is no longer in use.

Ah that means there is code? Yes, today I pushed the branch as “graesslin/kdecoration2” into kde:kwin git repository. To give it a proper try you also need the kde:kdecoration (master branch) and kde:breeze also on “graesslin/kdecoration2” branch. The new decoration API is working quite well and I’m rather satisfied. The memory usage of KWin dropped significantly. In a previous report I mentioned that KWin needs around 200 MB, right now my KWin only needs around 40 MB, the number of open windows is a little bit smaller, but still it shows in the right direction. And that’s without any optimisations. There is still some optimization potential in Breeze (check out our todos, all purple tasks are in Breeze) and in KWin (red tasks). Also a nice improvement is that the window decoration no longer flickers when resizing the window. This is a rather big annoyance of KWin 5.0. I expected that the new API would fix this issue, but seeing it confirmed is really nice 🙂

Last but not least the restart of KWin got faster which is a nice improvement for KWin developers, for users it’s not that important. The reason for this is that when we enabled/disabled compositing we recreated the window decorations. So when restarting KWin we first created all windows with their decoration before enabling compositing to just destroy them and create them again (yes it would have been possible to improve it, but it doesn’t hit users). Now with the new API there is no need to recreate the decoration. Only a Renderer is exchanged, but the rendering is delayed till it’s needed.

This screen shot does not only show the new Breeze decoration, but also some new features: when quick tiling a window the borders cornering the screen edges are removed. Also in the preview application one can see that the decoration scales which is nice for high-dpi screens. The decoration API follows the approach Plasma is using.

I have been running a KWin with the new decoration API since Monday, which means we are close to start the review process. But there’s of course still work to be done and I’d appreciate any help. The window tab API is not yet implemented, the configuration module needs adjustments to load and render the new deco and most important we have to port the existing decorations like Oxygen, Aurorae, deKorator and QtCurve. For the last three I want to improve the theme experience by allowing the plugin to say that it supports themes directly in the JSON meta data and point to where to find them. So the configuration module can just show all of them. The trick will be to pass the to be used theme to the factory method (we have a nice QVariantList there which can be used). Also the meta data will make it possible to point to GHNS configuration files so that we can not only download Aurorae themes from the configuration module, but also other themes.

KDecoration2 – The road ahead

Yesterday I blogged about why Breeze is not the default window decoration in KWin 5.0. The blog post touched a little bit the problems with our decoration API. In short: it’s QWidget based and that doesn’t fit our needs any more. It uses a QWidget as an X11 window. At the same time KWin intercepts the rendering and also input handling, redirects it and forwards it. So why use a QWidget at all? Also using a QWidget is quite a memory waste in the Qt5 world. The QWindow behind the QWidget uses a QXcbShmImage with the same size as the window. As explained in yesterdays blog post the window has the size of the managed window plus the decoration. So for a maximized window we hold an image of the size of the complete window while we just need the titlebar strip. We can do better 🙂

Our decoration API is also showing it’s age. It’s cumbersome to use, too difficult to use. In fact there is a KDecoration and a KCommonDecoration – the latter trying to make KDecoration easier to use by for example providing buttons. The API got extended several times to support more features which are all optional. The API is difficult to use from KWin side as it’s not stateful and quite often needs to call into the decoration API calling virtual methods the decoration API provider needs to implement. Last but not least it’s difficult to test new decorations as we don’t have a dedicated viewer application to test the interaction and painting. You have to kind of use KWin as the development host. Not the best solution.

The idea for a new API had been in the room for a long time. I opened a bug report for it more than two years ago. Last week I finally started with the implementation and tackled three things at the same time:

  • New decoration API
  • Viewer application
  • Breeze decoration

In the current state it looks like this:

The outer decoration is the existing Aurorae theme. It looks already quite good, but there is of course still lots of work to do. The API is not yet feature complete, it needs implementation in KWin and Breeze needs a pixel perfectionist to get it right (which I am not). And that’s where you can help! Thanks to our sysadmins we have a new todo board and I requested a project for KDecoration2 and prefilled it with very easy tasks. This is a wonderful opportunity to work on easy and new code and helping both KWin and the Visual Design Group achieving an important new step. Without your help we won’t have this in 5.1 and it would be so important for both KWin and the overall design of the Plasma desktop. So please grab the code and start hacking. Grabbing the code, where? The new decoration API can be found in the git repository kde:kdecoration, the viewer application in git repository kde:kdecoration-viewer and the new Breeze window decoration in git repository kde:breeze in branch “graesslin/kdecoration2”.

So what makes KDecoration2 better? Obviously it’s no longer QWidget or QWindow based. Instead it’s a pure QObject based API. It provides a paint method a plugin needs to implement which gets a QPainter passed into. This allows KWin to control the rendering and to render to the best suited backend for the current compositor (e.g. just a QImage or a Shm shared pixmap). Also the input handling will be controlled from the backend side by sending appropriate events to the decoration. The API takes care of all of the handling – activating the buttons forwarding title bar presses, etc. This alone makes the API hopefully much easier to use from plugin side. It also provides the base implementation for all the required buttons, so that the decoration only needs to provide the painting of the buttons. Simplified the API looks like the following:

There’s an additional singleton DecorationSettings which provides common settings for the decoration. Also there’s an additional second private API which must be implemented by a backend. This will allow us to use KDecoration2 in multiple places. I want to see it uses in KWin, but in future I’d also like to provide our decorations for QtWayland. For this I hope that KDecoration plugins can also be a solution.

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.

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?

Help porting KWin to Frameworks 5

With Akademy behind me and the situation about “what is master” in kde-workspace resolved I decided to switch my work away from Wayland towards getting KWin on top of Qt 5 and KDE Frameworks 5. After a few days of hacking the compilation of KWin is re-enabled in the frameworks-scratch branch of the kde-workspace git repository.

This means that KWin compiles, links and installs when compiling against KF5. A quite important step and only very few code areas got ifdefed. The preparation work of the last months showed it values as for example the compile errors due to QPixmap were extremely easy to resolve (just delete the code) without loss in functionality.

But of course at the moment KWin does not work yet when compiled against KF5 as the event filter is not yet ported to xcb. This is what I will focus on next so that we can soon start testing a KWin on 5 and start to adjust the areas which need to be tested against a running KWin, where “ship it, it compiles” is not enough.

Of course getting KWin to KF5 is still a long road and we need help for this. There are many, many tasks which are rather easy and do not need a working KWin. It’s just a matter of changing for example KPushButton into QPushButton and verify that it still compiles. This means that right now is a perfect time to get started with KWin hacking.

And obviously I started to prepare for that and created a wiki page for KWin on Frameworks. I plan to update this page whenever new information becomes available like how to run KWin on 5. Most important I created a Trello board listing the tasks which can be done to help the porting. I will add tasks as I notice them. So if you want to get involved, just ping me, tell me your trello username and I’ll add you to the board and start hacking. If you look at the list you will notice that some tasks are really simple. Let’s rock to get KWin working on Qt 5 as fast as possible to get an awesome next release.

The relationship between Plasma and KWin in Workspaces 2

Yesterday during the Tokamak 6 sprint in Nuremberg we discussed the role of KWin in Plasma Workspaces 2. At the moment in Plasma Workspaces 1 KWin is of course the recommended window manager and compositor, but it’s also possible to use a different window manager. Back in the days there were quite a lot of users who run Plasma with Compiz. In theory that shouldn’t matter because everything is standardized with EWMH and ICCCM. Over the years we added more and more extensions to EWMH. It’s all open source so anyone can implement these extensions (Compiz used to do so), nevertheless right now there is probably no other window manager available to offer the full experience except KWin.

Plasma Workspaces 2 will be released at an interesting point of time. We don’t want to do the transition to Qt 5 and Wayland at the same time, so it will still be X based. But we all agree that our future will be on Wayland and even if we use X as the windowing system our primary focus is on Wayland. With Wayland quite a few things will change. KWin will play a more important role as it will be the Wayland compositor – we do not plan to use Weston.

Given that we know that the Wayland shell interface only covers part of what Plasma needs and some of our needs are extremely Plasma specific (for example Activities) it would be tempting to say that we tie KWin to Plasma. Let’s face it: which other compositor will be there to replace KWin? The reference compositor will probably never accept Plasma specific patches for things like Activities, Compiz won’t be ported to Wayland and GNOME Shell will probably never be a solution for Plasma. For the small window managers we do not know whether they will go to Wayland at all, but I expect rather not, though I expect that we will see Weston forks/extensions for substitutions of tiling window managers.

We decided to resist the temptation to go the easy road, but instead will develop all our integration bits in a way that one could replace KWin by a different Wayland compositor, even if that is just a theoretical option. Of course we will not do any fallback modes for the case that one is using e.g. Weston without Plasma integration bits. So the features which we need might then just be disabled. Adding fallback modes would most likely just result in bit rotting code as nobody would use it.

Of course to make it possible that others can provide compatibility features we need to properly document our extensions and additional interfaces. Luckily Wayland implicitly forces us to do so. The general plan is to publish our extensions and also try to standardize what makes sense to be standardized and we hope that this would also benefit other projects. What we especially had in mind is of course Razor-Qt which already supports using KWin. By properly documenting all our Plasma-KWin communication channel, they can also use what is useful to them and it ensures that we don’t break KWin in a way that it gets unusable for Razor-Qt.

[Help KWin] Create a KConfigXT file for KWin’s configuration

Just the other day a user in IRC complained about a default in KWin. I thought that the default he expected, is the one which is set in KWin sources. So I opened the respective source file and saw my assumption confirmed. But still the user claimed that there is a different default and I believed him. Further investigation showed that the source code of the configuration module had a different default set. It’s probably like that for years but it shows a problem: the config values are written and read at different places and the hard coded default values might diverge.

This reminded me of the great project we had last year to migrate the configuration of the KWin effects to KConfigXT and of the project to transform the configuration modules in KWin to have ui files. The combination of both calls for a new project: let’s migrate KWin core to KConfigXT. Now this isn’t a project which we will be able to do in one go. So I will split it into three parts:

  1. Create the kcfg file
  2. Migrate KWin core
  3. Migrate the configuration modules

Let’s start with the first one: create the kcfg file. Interestingly we already have such a file in the kwin directory – last change: Nov 20th 2007. It might be that some of the options are still encoded correctly, but I rather doubt it and default values are missing anyway. So I suggest to start clean. I would like to split the task into creating the XML part for the different config groups in KWin, so that the tasks are small. Later on we can then put it together to have one complete file. The project is outlined in this wiki page. Just add yourself to a section if you want to work on it 🙂

[Help KWin] Save the Explosion Effect

One of our KWin Effects hasn’t seen much love over the last years and is in fact more broken than working. It’s a pure eye-candy effect which means that it is not at all in the development focus of the KWin team. The truth is, that we are tempted to just delete the effect because we won’t fix it. But of course there are users who like it and would be sad if it gets deleted.

Here you can help: if the issues gets fixed and the effect becomes maintained there is no need to remove it. So if you want to get your hands dirty with a small OpenGL based effect have a look at the Explosion effect and improve it. Have a look at Bug 312176 and all the linked reports to find the issues.

[Help KWin] Fix Warnings

Today I once more present some easy tasks to help the KWin development. This time it is a small coding task, though it’s not a very difficult task, but a very important one.

As you might know there is a new C++ standard available, which is called C++11. This standard provides quite some nice and useful additions to the language which we would like to use.

Unfortunately the new standard is not completely backwards compatible and there are some usages inside KWin which would no longer compile if we would enable C++11. This used to be totally valid code which did not even raise a warning. With gcc 4.7 we nowadays get a warning for all these code fragments which would not compile with C++11.

We need to fix those warnings, because we want to use C++11 in future and because they make it more difficult to spot the “real” warnings.

Therefore I set up a wiki page which contains all the warnings the compilation of KWin is currently causing and I would like to fix them all and that’s an easy way to help.

All you need is a current checkout of KWin and you need to be able to compile it with (at least) gcc 4.7. Please follow the instructions about building KWin. When you work on a warning just set the row in the table on the wiki page to InProgress and add yourself to the contact information. Please do this step as it prevents that multiple people start to work on it. Once you have a warning (or multiple) fixed, just open a review request on Review Board for group KWin.

If you work on it, please concentrate on warnings mentioning C++11.

[Help KWin] Update screen when Dim Inactive Effect Configuration Changes

Today I have a very easy coding task. In fact writing this blog post is more work than fixing it myself 🙂 I thought this is a wonderful task for anyone who wants to start contributing to KWin as a developer.

The task is documented in Bug 308283. If you want to work on it, just assign the bug to yourself, once you are finished either create a review request or upload a git format-patch to the bug report (git format-patch so that we can easily include it).

Please work on top of the KDE/4.9 branch as that should go into the next bug fix release and master and branch have diverged.