Tag Archives: KWin

KWin a solution for non-KDE based Desktop Environments?

Recently I have seen more comments about using KWin as a stand-alone window manager in other desktop environments. It looks like quite some users are looking for a replacement for Compiz nowadays. But of course especially among the users of the lightweight desktops there is the perception that one cannot use KWin because it is done by KDE.

So I thought I spent some time on explaining about what it actually means. Of course KWin is the window manager of the KDE Plasma workspaces. And this means it is part of the KDE source code module called “kde-workspace”. Most distributions provide one package or a set of packages which depend on each other for this workspace module. This means to install KWin one has to install what people consider to be “KDE”. But it doesn’t mean that one has to run any other part of the kde-workspaces. KWin is a standalone application which only depends on the kde libraries and requires a few runtime modules (e.g. the globalshortcuts daemon or kcmshell4). One does not have to run the Plasma desktop shell or systemsettings or any other application provided by the KDE community.

So installing KWin requires to install a few more applications, but all they will do is take up some space on your hard disk. I know that people are sometimes very concerned about it, so I run “du -h” on my kde install directory. This includes not just the kde-workspace module with its dependencies, but more or less everything we have in KDE’s git repository including things like an office suite, IDE, webbrowser, artwork and many other things one doesn’t need to run a window manager ;-) The result of all that is just 13 GB of disk usage. Given current storage costs (0.06 EUR/GB) this costs less than 1 EUR which is less than a cup of coffee where I live. And remember KWin will need less storage. The bare kde-window-manager package in Debian is just around 10 MB.

I understand that people care about the dependencies and think this is important. I just don’t think it’s of any importance in a world where a movie needs significantly more data storage. Still we care about the dependencies and we are working on breaking down the dependency chain as part of the frameworks modularization efforts. One of the results of this is that we have documented dependencies nowadays. And we are working on getting the dependency to the Plasma framework as a runtime-only dependency over QtQuick, so that people can put together themeing for KWin which does not pull in any bits of the Plasma dependency. Help on that is appreciated :-)

A more relevant issue is the question of memory usage due to running KWin. Unlike disk storage, memory storage is still rather constraint. Unfortunately it’s very difficult to provide correct measurements on the memory usage of a single KDE application. KDE applications have many shared libraries (e.g. Qt). So if KWin is the only Qt application, the relative memory usage is higher than when using several Qt applications as for example in LXDE on Qt.

Now a few highly non-scientific numbers: according to KSysGuard my self-compiled KWin (Qt4) uses around 40 MB of private memory and 38 MB of shared libraries (Qt, kdelibs, XLib, xcb, etc.). The memory usage also depends on what you use. If you activate the desktop cube effect with a 10 MB wallpaper put in the background, you will see this in the memory usage ;-) Just as another value for comparison: the iceweasel instance I’m writing this blog post in has a private memory usage of more than 700 MB. Of course KWin is with that in a different league than the minimalistic window managers, but one has to see that KWin provides more features and is a window manager and compositor. If one needs to run two applications to get close to the same feature set, it’s quite likely that the same amount of memory is needed. KWin has many features and there is no such thing as free-lunch in IT. It’s certainly possible to trim KWin down by not loading the KWin effects and ensuring that no scripts are loaded and simplified graphics.

Given that I can only recommend to give KWin a try and not to discard it because it is from KDE and might pull in some dependencies. Evaluate by the features we provide and you want to use and not by some random number on your hard disk or your memory usage.

KWin/5, QtQuick 2 and the caused changes for OpenGL

In the KWin/4 days our OpenGL implementation could be based on some assumptions. First of all only KWin creates an OpenGL context, none of the libraries, KWin depends on, uses OpenGL. From this it is possible to derive more assumptions, for example our compositing OpenGL context is always current. Which means that it’s possible to run any OpenGL code in any effect. No matter how the code path got triggered. Also we can link KWin against OpenGL or OpenGL ES. We don’t have to check with other libraries to prevent conflicts.

With KWin/5 these assumptions no longer hold. KWin uses QtQuick 2 and with that we pull in the Qt OpenGL module. One of the direct implications of this change is, that we are no longer able to provide kwin/OpenGL and kwin/OpenGLES at the same time. The compilation of KWin has to follow the compilation of the Qt OpenGL module. So compiling against OpenGLES is only possible if Qt is compiled for OpenGLES, which means that the option to run KWin on OpenGLES is probably non-existing on classic desktop computers and the option to run KWin on OpenGL is probably non-existing on ARM systems such as the Improv. Given that it’s no longer possible to compile both versions at the same time, the binary kwin_gles got removed. A kwin compiled against GLES is just called kwin.

With QtQuick also our assumption that only KWin creates an OpenGL context and makes it current doesn’t hold any more. In fact it could be that at any time Qt creates an OpenGL context and makes it current in the main GUI thread. Now people probably know that QtQuick 2 uses a rendering thread, so that should be fine, right? Well not quite. To decide whether QtQuick uses a rendering thread it creates a dummy context in the main gui thread and makes it current. So our assumption that our context is created once and then kept current, doesn’t hold any more. The first solution to this problem was to make our context current whenever we go into the repaint loop. That worked quite well, till I tested KWin/5 on my SandyBridge notebook.

The problem I stumbled upon is that Qt doesn’t use a rendering thread in all cases. For some hardware it prefers to use the main gui thread. One of them is SandyBridge Mobile, the hardware I am using on my notebook. This showed that the initial solution was not elaborated enough. With another context rendering in the same thread it showed that it’s quite likely that we hit conditions where our compositing context is not current. Resulting in e.g. not rendered window decorations, effects not able to load their textures, etc. etc.

These problems are hopefully solved, now. The effects API is extended by calls to make the context current and I tried to hunt down all effects which do OpenGL calls outside the repaint loop. Unfortunately given the large number of effects it’s still possible that some effects use it incorrectly. It will be difficult to track those down: so please test.

The case when QtQuick uses the main GUI thread for rendering illustrates that we in KWin are not the only ones having incorrect assumptions on OpenGL. QOpenGLContext assumes that every OpenGL context in a Qt application has been created through QOpenGLContext and that an OpenGL context is only made current on the current thread through the QOpenGLContext API. Especially if one uses glx or egl directly to make a context current QOpenGLContext doesn’t notice this and assumes that its own context is still current which can result in nastiness. This is circumvented in KWin now by making sure that QOpenGLContext has correct information once the compositing context is made current. Nevertheless we are still hitting a bug causing a crash. This one is also currently worked around in the development version by enforcing XRender based compositing on the hardware which uses the main GUI thread for rendering. On SandyBridge one can also use the environment variable QT_OPENGL_NO_SANITY_CHECK to force QtQuick to use a dedicated rendering thread as the problem why Qt uses the main gui thread is not relevant to KWin’s usage of QtQuick. KWin also checks for this environment variable and doesn’t force to XRender, if it is set.

Obviously one could question why we are not using QOpenGLContext given that this seems to conflict. We haven’t used Qt’s OpenGL module mostly for historic reasons. Of course I evaluated the option of using QOpenGLContext when investigating this issue and right now in Qt 5.2 it would not be an appropriate solution for the usage in KWin. It’s not possible to create a QOpenGLContext from a native context and even if it were possible our implementation is more flexible. KWin can be compiled against both egl and glx allowing to switch through an environment variable. Qt on the other hand supports either egl or glx, but not both at the same time. If I find time for this, I intend to improve the situation for Qt 5.3, so that we can consider the usage of QOpenGLContext once we depend on Qt 5.3. Switching to Qt’s OpenGL context wrapper would allow us to get rid of a considerable amount of code. I’m especially interested in the QOpenGLFunctions. Obviously that will only be a solution if KWin uses the same windowing system as Qt’s platform plugin. But that’s a problem for another day ;-)

Color Scheme syncing between window and it’s decoration

Some time ago I started Krita and I had the thought: well we can do better. The window decoration is just looking out of place. Everything is a nice dark color, but the window decoration isn’t. So I asked a few people what they think about making it better and the reaction was overall very positive and I started to investigate.

Right now I have a solution for KWin/5 which allows the window decoration to follow the color scheme of the window. Have a video:

At the moment it’s implemented mostly inside Oxygen, but I intend to move most of it to KColorScheme an KStyle directly, so that any KDE/Qt application can benefit from this new feature.

And of course I need to point out that all of that is possible without opening Pandora’s box of Client Side Window Decorations as Aaron said today.

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.

An unexpected journey

Since my last post quite some progress has been made in getting KWin working on top of a Wayland compositor. My main focus of work has been on the input stack. This is something I am not really familiar with as so far we did not have to care about it.

As some might know input handling in X11 is very insecure. Every application is able to listen to every key event. And in the KDE workspaces we obviously make use of these “features”. For example the global shortcut handling is implemented as a kded module listening to all key events and notifying the application via D-Bus that the shortcut got triggered. In a post-X11 world this will not work any more: applications are no longer able to listen to all key events.

One of the important tasks therefore is to not send all input events to the
X-Server but just to the window which should get it, or to handle the input events inside KWin and discard them without passing to the applications. My current branch already supports activating screen edges and using fullscreen effects like Present Windows completely without passing the input events through X. This means that some of the longstanding issues are automatically resolved. We no longer “steal” the screen edges from applications and starting the screen locker should be possible even if present windows is active (not tested and still needs some screen locker support in KWin).

But this also means that features like the global shortcut handling start to break. Mostly because kded is not listening on my virtual X but that’s just detail ;-) So I also had to start working on global shortcut support inside KWin – otherwise I would have had a hard time to use some of the important features like switching desktops or using Alt+Tab. At the moment the latest code only supports KWin’s internal shortcuts, but global support for kglobalacceld will have to follow. We had some ideas on how to improve global shortcut handling in general anyway.

When the infrastructure was in place I couldn’t resist the temptation to work on features which had been requested for a long time and were not really possible to do with X11 (or only with huge hacks): mouse shortcuts. Ctrl+Alt+left click activates desktop cube. But that’s not enough. While sitting in the Kubuntu Developer Summit I added also mouse wheel support which allows us to ctrl+alt+wheel to switch desktops and also to use the zoom effect. This work can be found in branch kwin/global-shortcuts on my personal workspace clone.

I hope that we will soon have a decision on the “what’s master” discussion and I can start merging the changes in. Once this is done I plan to switch focus to the Qt 5 port and concentrate on this for the next few weeks.

Nevertheless this should not be a reason to stop the work on the Wayland efforts. There are so many small things which can be done and lots of low hanging fruit. I will try to setup a trello board with a few tasks, so that interested developers could start picking up some easy tasks and get their hands dirty. Once something is in place I’ll write another post.

More Software Compositing

One of the most often repeated misconceptions about Wayland is that it requires hardware acceleration. I would have thought that this issues would have been resolved once the reference compositor, Weston, supported rendering through Pixman. The reason for this misconception is most likely that the earlier versions of Weston required hardware acceleration.

Now KWin in 4.11 introduces the same mistake. Our experimental Wayland support is only available in the OpenGL compositor – even OpenGL ES is not supported (something is broken on my system I cannot start it). I think this is a bad situation. One of the huge advantages of KWin is the exchangeable compositor allowing to switch to software based XRender in case there are no proper drivers available. In fact KWin switches automatically to XRender if it detects a driver which recommends the XRender backend (e.g. software rasterizer).

So last week I started to work on some new Wayland related features and extended the XRender compositor in a way that it renders to a Wayland surface. It’s a pretty simple setup. Our XRender compositor uses an off-screen pixmap for rendering. The adjusted backend uses a pixmap created through XShm, so we get the frame rendered into a shared memory segment. From there we just copy it into a shared memory Wayland buffer to share it with the Wayland compositor. It would be better if we could create the shared Wayland buffer directly from the XShm segment, but I did not see a solution on how to achieve this.

In the end it’s also not really relevant. After all we want to use Wayland and the last thing we want to do on Wayland is using an X11 rendering API for compositing. So we can consider this more as a proof-of-concept and as a task so that I can get more familiar with Wayland ;-) It helped me to improve the code, so it was worth the effort. Even if it is a more academic solution it serves a concrete use-case: KWin uses XRender as a fallback and we can expect that the backend works. Given that we have to enforce compositing in future, it’s good to know that all backends work. The current state of this work can be found in branch kwin/wayland-backend of my clone (note: the link might change in case I force push).

Video on YouTube

If XRender is an academic solution, we are still facing the problem that we lost our software compositor. So I thought I need to also do something about this problem and started to work on a new compositing backend based on QPainter. It’s a quite simple compositor which uses a QImage as the rendering target. The QImage is created directly from the Wayland buffer, so in opposite to the XRender backend we don’t have the needless memory copy from one to another buffer. This is a very interesting compositor as it’s the first part of KWin which has been written from scratch only with Wayland in mind. It doesn’t support X11 (at the moment). This is the first new compositor written in years, so I found some things to improve and which are already under review. And as it was much easier to write a new compositing backend than I expected, I decided to document it in our wiki. It would be totally awesome if someone could have a look at it and write a dedicated compositor for the RaspberryPi ;-) The new compositor can be found in branch kwin/qpainter-scene.

The switch to Wayland does not only affect our software compositors, but compositing in general. So far KWin has always had the possibility to not require compositing. This doesn’t make any sense in a Wayland world. So I needed to teach KWin that we might need to enforce compositing. Of course on X11 we still want to have the option to disable compositing, so the changes only affect the Wayland backend. When starting KWin with the Wayland display environment variable set, KWin will require compositing. Even if it is disabled in the config options it will be enabled. Even more it ignores the shortcut to suspend compositing and options like unredirection of fullscreen windows. But still the backend might fail and in this case KWin is just exiting. There is no need to continue execution if one cannot see the output. This work can be found in branch kwin/enforce-compositing (which also contains all the other mentioned branches).

What we did in KWin 4.11

With the release of the 4.11 Beta 1 behind us it’s a good moment to look back on this last half year on development. KWin 4.11 is a very important release for us. As you might have heard at the last Plasma sprint we decided to make 4.11 the last release of the KDE workspaces based on Qt 4. Fear not: the KDE Software Compilation with all it’s great application will see a 4.12 release – at least I have not heard anything else, just the workspaces need some time to do the Qt 5 transition. In addition we want to provide extended bug fix releases for the 4.11 release of the workspaces. So 4.11 is a very important release – being the bridge towards Qt 5.

This is clearly what dominated the development of this release cycle. While porting to Qt 5 is easy in 99 % of the cases, KWin hits the 1 remaining per cent. There are many non-portable X11 specific features in Qt 4 and sometimes I think we used them all and all of them got removed in Qt 5. That’s not a bad thing – in fact I think it’s a good thing. I don’t want to go into detail about the problems we hit and why we used these Qt features in the first place – if you are interested come to my Akademy talk.

In many cases the changes in Qt required to rethink the problem. A good example is that a QPixmap no longer references an XPixmap which we heavily used during rendering the window decorations. This was causing us quite some performance problems with the combination of Qt graphics system raster and the XRender compositor. At the moment I’m running this combination without any noticeable performance difference thanks to the restructuring forced by preparing for Qt 5. Also in the OpenGL case the decoration rendering got quite improved thanks to Fredrik forcing me to improve the proposed changes and also doing some further changes.

Speaking on performance improvements: Fredrik reworked our OpenGL 2 compositor code base and also introduced a new OpenGL 3.1 code path. By default we still use OpenGL 2 with the fallback to OpenGL 1, but one can easily switch. If the hardware doesn’t support OpenGL 3.1 it automatically falls back to OpenGL 2 or OpenGL 1. When running kwin_gles we default to OpenGL ES 3.0 if present otherwise OpenGL ES 2.0 is used.

But that’s not the only change done to the OpenGL compositor. Thomas and Ralf worked on improving our v-sync behavior. There are now multiple strategies one can choose from – this should help to serve all use cases and setups in a better way. Buffer age support has not made it for 4.11 yet, but I’m quite confident that this will end up in the next release.

One of the tasks we continued from 4.10 is the porting to XCB. This also forced us to rethink some of our code. One of the areas which got rewritten because of this is the screen edge handling. It’s now finally multi-screen aware, but still only the four real corners can be configured, corners between screens don’t make much sense. And here with the screen edges we have one of the few user visible changes in KWin: a highlight when approaching the edge. So this hidden feature is finally no longer hidden.

Another small visual change is concerning the outline when using quick tiling/maximizing on screen edges. The outline should now better indicate what area will be covered by the window. Also based on common feedback the moved window is put above the outline. This used to cause problems with dark Plasma themes causing.

The last changes I want to mention are some effects rewritten in JavaScript. This is mostly to improve the maintainability of the code. The JavaScript effect API is optimized for animating windows based on state changes. If I remember correctly the rewritten effects are Dialog Parent, Login, ScaleIn and Translucency. Thanks to Kai Uwe for helping us with these tasks. There are still a lot of effects which would benefit from this work. So get your editor ready ;-)

Overall the effects have seen some changes. BoxSwitch effect got finally the kick as the functionality is now completely available in the QML Window Switching functionality. Explosion got the kick as it has been unmaintained and broken for a long time. The Outline is no longer implemented as an effect, but moved back into KWin core. The add/remove desktop button in Desktop Grid and the close window button in Present Windows got reworked with QML and Plasma components – another nice improvement thanks to Qt 5. Present Windows has also an unpopular change: the mouse action for closing a window got removed. But also we have the code ready to rewrite Present Windows and Desktop Grid with QML (a task for next version). The Maximize window effect got a nice improvement in the OpenGL compositor: it cross fades with the previous window texture which removes the up/down scaling which was not looking that nice. Thanks to Aurelien for writing software exposing bugs in KWin which require reworks allowing to implement this feature.

I’m quite sure that I have forgotten to mention many really important changes which we did over the last half year. It’s a long time and after all we changed 666 files with 32516 insertions and 29217 deletions (git diff –shortstat v4.10.0..master — kwin (master being 4a172a9d)) including the changes by scripty.

Starting a full KDE Plasma session in Wayland

This week there will be the release of KDE SC 4.11 Beta 1 and this will come with an interesting new feature: an experimental Wayland backend inside KWin. This backend does not allow to manage Wayland clients, but uses another Wayland compositor as the rendering target. Instead of rendering to an X window, KWin renders to a Wayland surface. From an architecture point of view this means that there is a Wayland system compositor and KWin is running as a Wayland session compositor (although KWin is not yet a Wayland compositor).

Disclaimer: this is a highly experimental feature and not intended for productive usage. Please do not report any bug reports in the bug tracker. If you find an issue please open your editor, hack and submit a review request.

Now I expect that you are also excited about Wayland and that you want to run your KDE Plasma session on top of Wayland instead of X, right? So here are the instructions: First of all you need to change the “Tearing Prevention (VSync)” in KWin’s Advanced desktop effects settings to “Full scene repaints”. This is needed because KWin does not yet support the buffer-age extension needed to properly repaint in Wayland. Note: when using X11 you probably don’t want to use this option, it wastes quite some power.

The KDE Plasma session startup is controlled by a script called “startkde”. In order to start the KDE Plasma session with Wayland we also need this script, but need to have a few environment variables set to tell KWin that it should use Wayland. So best copy this script and call it” startkde-wayland”. Edit this file and add the following exports after the shebang:

export DISPLAY=:99
export WAYLAND_DISPLAY=wayland-system-0
export KWIN_OPENGL_INTERFACE=egl_wayland

Now all we need is another small shell script to start Wayland, Xvfb and the modified startkde script. Let’s call it kwayland:

#!/bin/sh
weston-launch -- --socket=wayland-system-0 &
Xvfb -screen 0 1366x768x24 :99 &
startkde-wayland &

Please change the screen resolution to the one used by your screen. KWin is not yet able to update the resolution of the X server to what Weston uses. This also means that you cannot change the resolution or add multiple screens (as I said: it’s an experimental feature).

Now log out of your running KDE session, switch to a tty and stop the still running X server. With X out of the way you can start the kwayland script. You should see Weston starting and shortly afterwards KWin should take over. If everything is configured correctly you should see the normal splash screen (seems like my system is not configured correctly).

Once the system is fully started you can just use it. If everything works fine, you should not even notice any difference, though there are still limitations, like only the three mouse buttons of my touchpad are supported ;-) I would post a screenshot but it’s fairly uninteresting as one cannot see a difference.

This blog post was written in a KDE Plasma session running in Wayland.

New KWin Scripting Feature in 4.11

Today is the feature freeze for 4.11 which is a good point in time to blog about the new functionality in KWin Scripting in the upcoming 4.11 release.

Configuration Interfaces

Since 4.11 our scripted components support configuration interfaces. Already in previous releases it was possible to define a KConfigXT file which can be read in the script. In 4.11 it’s now possible to have a ui-file bound to the KConfigXT file and KWin generates a config module from these two files. All that is needed is to modify the metadata.desktop file so that KWin knows that this script comes with a config interface:

X-KDE-PluginInfo-Name=kwin4_effect_foo
X-KDE-PluginKeyword=kwin4_effect_foo
X-KDE-Library=kcm_kwin4_genericscripted
X-KDE-ParentComponents=kwin4_effect_foo

The X-KDE-Library needs to be set to “kcm_kwin4_effect_genericscripted” and X-KDE-ParentComponents and X-KDE-PluginKeyword need to have the same value as X-KDE-PluginInfo-Name. The KConfigXT file is expected in contents/config/main.xml and the ui-file is expected in contents/ui/config.ui.

If these few steps are followed the effect respectively the script KCM shows a configuration button for the component.

Set and Cancel Animations

The animation API got a small addition: each animation has an id which can be canceled later on with the id. Cancel stops the animation immediately, it is not reverting the animation. So if one wants to revert the animation one still needs to schedule an additional animation.

Canceling an animation for itself is not that interesting, but in combination with another new feature it becomes very important: set animations. The new set animations are just like a normal animation but they stay in the final animation position until the animation gets canceled. A normal animation just performs the state changes, e.g. fading in or out a window. But it’s not possible to fade out a window and keep it faded out. When the animation ended the window will be visible again. Now the new set animation will keep the window faded out. This is used for example in the JavaScript version of the translucency effect to animate the moving of a window:

moveResize: {
    start: function (window) {
        window.translucencyMoveResizeAnimations = set({
            window: window,
            duration: translucencyEffect.settings.duration,
            animations: [{
                type: Effect.Opacity,
                to: translucencyEffect.settings.moveresize / 100.0
            }]
        });
    },
    finish: function (window) {
        if (window.translucencyMoveResizeAnimations !== undefined) {
            // start revert animation
            animate({
                window: window,
                duration: translucencyEffect.settings.duration,
                animations: [{
                    type: Effect.Opacity,
                    from: translucencyEffect.settings.moveresize / 100.0
                }]
            });
            // and cancel previous animation
            cancel(window.translucencyMoveResizeAnimations);
            window.translucencyMoveResizeAnimations = undefined;
        }
    }
}

This code snippet shows how to use the set animation and where one can best store the returned id: just use dynamic properties on the window. Also it shows how the animation can be reverted by specifying an animation in the opposite direction.

When using the set functionality one needs to be aware of one aspect of the behavior which can be considered as a disadvantage: the window will considered to be rendered with this animation until it gets canceled. Even if the window gets closed, minimized, activity changed or virtual desktop changes. The window will be there. So one needs to connect to events which could make windows go away and cancel the animations. Also when a window becomes visible again one should start the set animation again. There is a very easy test to see whether a window is currently visible: a new property called visible which is defined on the EffectWindow. It’s true if the window is currently not minimized, on the current desktop and on the current activity.

New Animation Types

4.11 also allows to animate in two new ways. There is Effect.DecorationOpacity which allows to just animate the opacity of the window decoration without changing the opacity of the whole window. Like before using Effect.Opacity animates both window content and window decoration. Obviously this only works with server side decorations.

The other new animation type is Effect.CrossFadePrevious which is a rather interesting new animation type for improving animations when the size of the window changes. When used KWin will keep the previous window texture and render it on top of the current window texture. This allows to cross fade from the previous window size to the new window size. If one wants to see it in action: the maximize effect is using it. This feature is currently only available in the OpenGL compositors.

New QML Components

The KWin QML Scripting API got extended by one new component: DesktopThumbnailItem. This component can render a preview of a virtual desktop:

KWin.DesktopThumbnailItem {
    id: thumbnailItem
    clip: true
    desktop: model.desktop
    anchors {
        fill: parent
    }
}

This component is used for example in one of the new desktop switchers.

Client Models

4.11 comes with a set of new models which can be instantiated in QML.

ClientFilterModel {
    id: filterModel
    clientModel: ClientModelByScreen {
        exclusions: ClientModel.DockWindowsExclusion
    }
    filter: screens.filter
}

These models are meant to be the base for functionality like Desktop Grid or Present Windows. 4.11 includes a SimpleClientModel, ClientModelByScreen and ClientModelByScreenAndDesktop. More models can easily be added, just let me know what you need. Also there is the ClientFilterModel which is a helper model to perform searches like known from the Present Windows effect.

Although these models are shipped in 4.11 KWin does not yet use them. They are meant to replace Present Windows and Desktop Grid in future, but this has to wait for QtQuick 2.