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:


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
                window: window,
                duration: translucencyEffect.settings.duration,
                animations: [{
                    type: Effect.Opacity,
                    from: translucencyEffect.settings.moveresize / 100.0
            // and cancel previous animation
            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.

Hitting walls – a story of Present Windows 2

One of my favorite User Experience elements in KWin is the Present Windows/Desktop Grid combination. For me those are the most important elements to switch between windows and virtual desktops. Although Present Windows and Desktop Grid are two different “effects”, I consider them us one because of their very similar functionality. The primary use case for both is to change the active window, the main difference is that Desktop Grid sorts the windows by virtual desktops.

The effects are so similar that they even share the code to lay out the windows. Nevertheless there are quite some differences in the functionality. The following features are only available in Present Windows:

  • Filtering of windows
  • Icon and caption on each window
  • Closing windows through a button shown on hover
  • Enlarging windows on hover
  • Mouse Actions
  • External activation (used by Netbook Shell)

On the other hand there are features in Desktop Grid not available in Present Windows:

  • Drag windows from one screen to another
  • Add/remove virtual desktops

The difference in functionality cannot be explained – there is just no reason for it. This is clearly a problem for our users – the effects look identical, but they behave differently. From all I learned about usability this is pretty bad because it teaches users to not trust systems.

The obvious answer would be to merge those two effects. But here we have a problem. Present Windows has been implemented to be Present Windows – no matter how we tweak it, it will be Present Windows. And Desktop Grid has been implemented as a Desktop Grid – no matter how we tweak it, it will be Desktop Grid.

I know that people will tell me that nothing is impossible. Of course one could hack around and make the effects be the same. But we have been there and tried to bring non-Present Windows functionality into Present Windows. I once implemented an Alt+Tab mode in Present Windows – a huge mistake. All it did was adding lots and lots of special case handling to make it work. And it castrated the effect. It only supported one screen (needed of course special hacks), it didn’t support filtering (keyboard grab hold by Alt+Tab framework) and so on and on. It never made any sense and I am very glad that I realized this error and removed the Alt+Tab mode again.

But also with Desktop Grid we made the experience by adding the layout mode of Present Windows. It wasn’t good for the code base. Nowadays, after I implemented that addition, I compare the code base of Desktop Grid effect to a Jenga tower which is already shaking and I fear that if I touch it to change something it will completely collapse.

A merge would only be possible by removing features and that is always difficult. People were really upset when I removed the Alt+Tab mode of Present Windows. Arguments do not work, giving replacements does not help and trying to improve the workflow is of course not welcome.

What remains would be a complete rewrite from scratch. But that’s a task so large that I consider it as a possibility for a Google Summer of Code project. Together the two effects have more than 4000 lines of code. It’s nothing we could do in parallel to our normal work and rewriting as a KWin Effect does not really make sense. Yes one can use Effects for that but it’s rather limited.

One of the most clear disadvantages is that Effects require Compositing. While having always composited systems becomes more and more the reality, there is still no reason why there should be the break in the user workflow when turning off Compositing and I have had many discussions with users who did not understand that.

But the real problem is that we do not have a toolkit inside the Effects. We are down to key press/release events and mouse motion/press/release events. That’s rather limited. For the close button inside Present Windows we do quite some hacks to get the mouse events injected into the QWidget. It’s a hack and nothing that scales. Key events are not composed correctly – for example on my English keyboard I’m not able to write letters like “ä, ß” in Present Windows. But the real problem is the handling of things like the drag and drop of windows in Desktop Grid. The code is extremely nested (seven indentation levels) and has to cover many, many corner cases. It just shows how difficult it is to get that handled correctly with different modes.

But since recently we have a technology which solves many of these problems: QML. With QML we get a toolkit which we can use to properly interact with the windows and which is supported in both composited and non-composited setups. In combination with our KWin scripting framework we have capabilities which are quite similar to what our effects can do. As a nice side-effect QML forces us to separate logic from visualization which means that the logic of Present Windows/Desktop Grid could be reused and combined with new ideas of how to represent the data.

This week the logic part entered KWin’s source repository in form of a QAbstractItemModel which is exported to QML. The model is quite flexible and allows to sort the windows in multiple levels – currently it supports screens, virtual desktops and activities. In addition one can specify whether a window should be excluded. That’s for example important to have the different modes of Present Windows – there is one mode for only current desktop and one mode for only windows of the currently active application.

Having a model makes it rather easy to support filtering – we just need to connect it to a QSortFilterProxyModel and such a model is already provided and exported to KWin’s QML binding.

Implementing the logic for Desktop Grid inside QML becomes now as simple as:

ClientFilterModel {
    id: filterModel
    clientModel: ClientModelByScreenAndDesktop {
        exclusions: ClientModel.NotAcceptingFocusExclusion | ...
    filter: filterItem.text

The idea is now to use this as a base for what I call “Present Windows 2”. It’s nothing I target for 4.11, because of the complexity of Present Windows and Desktop Grid. I hope that many things become easier once we are on Qt 5 and QtQuick 2. So it’s something I want to have for Plasma Workspaces 2. I’m still wondering whether to optionally include the current proof of concept QML script which renders a screen like this:

Aus KWin

One can already see the improvements like an always visible filter area. That’s one of the real disadvantages of the existing Present Windows effect: one doesn’t get any hint that it is possible to filter the shown windows. Also a clear improvement in this variant is the always visible close button for each of the windows.

The new models included in KWin might also get new tasks I haven’t thought about when I started to work on it. Our Plasma developers noticed that this would be a rather good base for the tasks applet. Whether that’s possible or not we do not yet know, but it would have clear advantages to have a shared code base for all the different ways of getting an overview of open windows.

(Sorry for having once again written such a long blog post)

QML Support for Window Decorations

Implementing a new window decoration for KWin is not the easiest thing to do. While the API has hardly changed since early 3.x releases it is not very Qt like and requires a strong understanding of how the window decoration in KWin works. To design a window decoration you basically have three options which come with KWin:

  • Subclass KDecoration
  • Subclass KCommonDecoration
  • Design an Aurorae theme

KDecoration gives a developer the most powerful options. The developer can design the decoration in whatever way he likes. But it also means that the developer has to take care about everything himself. E.g. properly laying out the buttons, handling mouse events on the decoration, ensuring the right resize handles are shown, etc. etc.

An easier way is to implement KCommonDecoration which already implements the common aspects of a decoration. For example a normal decoration has some buttons on the left and some buttons on the right side. The main task of a developer is to define how large various parts of the decoration should be, e.g. the margin between the left buttons and the caption. This of course limits the possibilities with the decoration.

The third option is to design an Aurorae theme which means just creating a few SVG elements. This is of course for designers the best option, but again very limiting. If a feature is not provided by the theme engine it cannot be represented. In the same way there are third party deKorator themes available.

The C++ based decoration APIs seem to be too difficult to be used. If we look at kde-look we see that there are just 14 native decorations available and some of them are forks or old versions of decorations available in KWin directly. But there are already 79 Aurorae themes available and more than 150 deKorator themes.

What seems to be a real issue concerning 3rd party usage can be validated if we just look into the KWin source base. In 4.9 we ship four window decorations: the Aurorae theme engine, Oxygen, Plastik, b2 and Laptop. Together they are 10 kSLOC of C++ code and 1 kSLOC QML code (Aurorae). Before Aurorae got ported to QML the size of the decorations was 13 kSLOC. Overall that is about 10 per cent of the KWin source base, which is rather large.

When I ported Aurorae to QML one of the nice results was that I had to add a QProperty based API to communicate with QML in the first place. If this were the actual API writing a window decoration would be probably much easier. As a first step in that direction I started adding generic QML support to Aurorae.

Following the general direction of all scriptable elements in KWin I decided to go for the well known Plasma Package structure, and added support to Aurorae to use a QML file from a package instead of the own QML file. The patch for this had been in my workspace for quite some time but I did not have any code to actually test whether it works.

So yesterday I started to re-implement one of our C++ based decorations in QML. I decided for Plastik as the decoration is in fact broken and had been scheduled for removal. We have not yet removed it as we acknowledge the user’s wish to have the KDE 3 look still around. But we are unhappy with having a decoration which is broken and unmaintained. So having a QML replacement would be something rather nice.

After one and a half days of work I’m proud to say that writing decorations in QML is possible. The changes to the configuration module and Aurorae itself are already under code review, the new Plastik still needs some love. But the decoration is already completely useable as can be seen in this screen shot:

In the current state the decoration consists of 370 lines of QML code and I expect to need an additional 100 lines to finish the buttons (they are already functional, that is the close button closes the window) and add some of the configuration options. The same API in C++ consists of 1500 lines of code. So we do not only get fewer lines of code but also a more readable and easier to maintain codebase. For something like a window decoration a declarative approach is much better suited than the imperative C++ way of painting elements.

Overall the new QML API will provide the same powerful features as the KDecoration API, but also provides convenience functionality as KCommonDecoration, e.g. a button group taking care of laying out the decoration buttons. To make development of QML based decorations quite simple support is currently being added to Plasmate as part of the Google Summer of Code project. So you will be able to design and also test the decoration directly from inside Plasmate. This is also quite some improvement as with C++ the only way to test a decoration is to use it in KWin, which can be quite nasty during development.

The API will need some more love till I’m quite confident to provide it’s usage but there is enough time till 4.10 🙂 So I hope that we can provide a better decoration experience in 4.10. I have a few ideas concerning the usage of QML based decorations in KWin and are looking forward to experiment with them.

Enabling Others to do Awesome

Recently Aaron wrote a blog series for the introduction of Spark, I want to cite a central saying of one post:

I want the things which I help make to become opportunities for others in their turn to participate with their own voice, their own movement and their own passion.

If I reflect my own motivation for my work on KWin and especially the areas of work I decided to work on in the 4.9 cycle I see quite some parallels to the paragraph cited above. But personally I would phrase it slightly different:

I want to help others to do awesome.

This describes perfectly what I am currently working on. I no longer want to write fancy effects – in fact I stopped adding effects quite some time ago. I don’t want to extend KWin to be the window manager which incorporates all other window manager concepts no matter how useful they are – we stopped doing that as well.

But still I want that our users get the window manager they want. Whether it is fancy effects or a tiling window manager or new concepts for virtual desktops, KWin should be the base for it.

At the heart of all these efforts we have the scripting bindings. While we already had bindings since 4.6 they never really got used – this will change 🙂 But JavaScript bindings is just one part of the game, the other part is declarative, that is QML, bindings.

In 4.8 we already experimented with QML for the window switcher layouts to test whether QML fits our needs and I am very happy so far with it. But 4.8 does not yet include the possibility to really write own layouts. While it is possible to do so, there is no way to configure a custom one or even distribute this.

For 4.9 the installation of the window switcher has been adjusted to use the Plasma Package structure which makes it possible to install window switcher through the plasmapkg tool. But this is only part of it: plasmapkg has been extended to support any kind of scriptable KWin content, be it window switchers, KWin scripts or KWin effects written in JavaScript (decoration to be added soon).

For this KWin scripts follow also the Plasma Package structure which is quite awesome as it finally allows to dynamically enable/disable scripts through our KCM:

This dialog wants to tell me: “I want Get Hot New Stuff integration” to directly download new scripts from the Internet. And sure it does need that and this will be added for the 4.9 release.

The screenshot shows two scripts I’m currently working on – both will be shipped with KWin in 4.9. Videowall is a script which scales fullscreen video players over all attached screens to generate a video wall. This is the first script which actually replaces functionality from KWin core. KWin had the functionality to disable multiscreen support for fullscreen windows and that really cluttered both code and UI. And it just did not make any sense. There are just no valid usecases to have in general fullscreen windows span all screens, except for video walls. And that’s what we have here: a small KWin script to make an obsoleted functionality sane. We improved KWin for everyone by removing an difficult and confusing control module without taking away the functionality for expert users.

But even more interesting than the video wall is the other script. This is not a JavaScript based KWin script, but a declarative QML script. It will replace the existing C++ based implementation of the desktop change OSD without any functionality loss. Which means less code and much more readable code 🙂

And what’s really awesome: JavaScript and QML have the same bindings, the API is exactly the same. So going from QML to JavaScript and vice versa is extremely simple. But that’s not all with QML based KWin scripts you can include live window thumbnails. So this is a technology to allow you to do awesome new switchers like Present Windows or Desktop Grid.

As you notice I’m currently dogfooding the bindings to myself. This helps me to see what is needed, what can be improved and to ensure that the bindings will work for any given usecase we can imagine. My wish is to see for example the complete window tiling support in KWin to be rewritten as a KWin script. This should be possible and would proof that you can use scripting to get a completely different window management.

So if you want to make awesome things with your window manager, now is the time to get started. Don’t hesitate to contact me and demand further bindings if anything is missing.

Disclaimer: QML support has not yet been merged into master.

Aurorae 3: Window Decorations with QtQuick

Once upon a time there was a window decoration which was KDE’s default decoration. But years ago it fell into a deep sleep. The world changed while the decoration slept. Compositing was added, decorations received shadows, Qt introduced the graphics system raster and many many more changes.

Now after years the decoration temporarily woke up, but it is no longer a beauty, but ugly and old. The changing world made the decoration break. The decoration’s bits started to rot and this is visible. The truth is that the decoration will stay in the broken state as there is nobody who would want to fix it or anybody knowing the code.

What I just highlighted here is true for basically all old decorations. Of the decorations we ship only Oxygen and my theme engine Aurorae are maintained. This is a situation which can no longer continue. We have to face the truth and remove all old decorations.

But of course we don’t want to remove decorations without adequate replacement and this leads us to the story of Aurorae.

Aurorae was written to experiment with new features introduced in KWin 4.3. It was based on our common decoration API and by that is rather limited. So for 4.5 I decided to port it to the generic decoration API and reimplement with GraphicsScene instead of QWidgets. Aurorae allowed to download decorations through Get Hot New Stuff.

But given that it is a theme engine the possibilities are still very limited. Only what the theme engine supports can be rendered. Porting our old decorations to the theme engine might not be possible and not to be recommended.

But still we would like to have those decorations on a modern basis without the maintenance costs. So I started to port Aurorae to QML. This does not only give us a more powerful theme engine but also introduces QML bindings for window decorations, allowing everybody to write decorations with QtQuick.

So we can write themes without the limitations of a theme engine 🙂 This does not only remove 3000 lines of C++ code and replaces it by around 1000 lines of QML code, but also gives us an interactive decoration control module.

Interactive decoration control module

For Aurorae based themes all the buttons are interactive giving our users the possibility to really try the decoration before using it. But that’s not where it will end. I want to have new themes not based on Aurorae but using QML directly. For that I want to use the Plasma Package structure and would love to see integration in Plasmate. Another idea is to support deKorator themes inside QML.

But as always this does not come without disadvantages. Not all features which were possible with Aurorae will be available in Aurorae 3. Some features will also be dropped because hardly any theme makes use of the features, for example special backgrounds for non-composited setups. Aurorae 3 will hardly work without compositing, so it might be that we will make it a hard requirement somehow.

I hope to see many innovative QML based window decorations in 4.9.

What’s new in KWin Scripting?

First of all a happy and successful 2012 to everyone. Let’s work together to make this year a great success for KDE!

One of the big topics in 2012 for my development efforts in KWin will be JavaScript bindings and QML. This is a technology which will allow our users to build their own custom window manager giving even greater power to our static window rules as before. It will also reduce our maintenance need when major parts of our UI can be transitioned to either QML or JavaScript.

The work on this area has already started and the first code set has been merged into master (aka 4.9). The old scripting API had manually crafted bindings for around 30 properties for windows. Now the API is generated and everything that is available for effects is also exported to JavaScript, which means more than 60 properties, more properties than before are writable and many more signals are available. Interestingly I could drop several hundreds lines of code by exporting more properties and the code becomes cleaner and better documented. These are changes I really like 🙂

The API documentation of KWin scripting is now auto-generated through Doxygen and already imported to techbase together with detailed Update Notes on what changed. If you run master and use KWin scripting be aware that you have to adjust the script. Exactly the same API will be available in QML and also the Effects API is very close – given that the property names are inspired by the Effects API.

One of my favorite changes is that our Plasma Desktop Console is now able to execute KWin Scripts:
Plasma Desktop Console executing a KWin script

To open just use KRunner and type the new keyword “wm console” or start the desktop console and switch using the toolbar button.

This is a very important change for me during development as I can easily test whether my scripts are correct and most important my implementation. But also for users it means that scripts can be tried at runtime and don’t require a KWin restart any more. So adjusting the runtime behavior becomes possible.

So what’s next? I am currently with the progress quite satisfied with the work done so far on scripting and will now concentrate on two other areas first: getting my unmerged kickoff-qml and screenlocker branch into master. Both require still a little bit of work. After that scripting and QML get my number one priority again.

Experience from Porting Kickoff to QML

As mentioned last week I started to port Kickoff to QML as a training project. Now I am happy to announce that Kickoff with QML is functional and can already be used. If you want to give it a try, just checkout the kickoff-qml branch in kde-workspace and rebuild the kickoff applet. It does not overwrite the existing applet, but adds a second one called “kickoff” instead of “Application launcher”.
Kickoff QML Application View

As we can see in the screenshot Kickoff got connected to all the Models, so we can browse all the tabs, the applications and perform search.

The actual idea was to just do some QML training, but it turned out to be more a training on Qt Models. The Kickoff code is let’s call it interesting. All the tabs have an underlying Model, but what was really surpising is that all Models have a tree like structure. For the Applications Model this was to be expected, but why are the Favorites in a tree structure? As QML is still rather limited for Tree Views I changed the favorites and leave model to be a plain list model which makes it easy to use.

The systems model (applications, places and removable devices) turned out to be more challenging. It uses a QProxyModel instead of QStandardItemModels and merges the applications and places into one Model again in a tree structure. Changing this to no longer being a tree structure seemed non-trivial and I did not want to touch the C++ code. So I started to implement a Tree view in QML for the system tab. Finally I had the QML code to play around with to improve my skills.

After I succeeded in rendering a tree view I noticed a new problem: both places and removable devices showed the same entries and too many entries. It took me quite some time to figure out the problem: the Model is buggy. The proxying was not done correctly and the view so far filtered out entries not relevant to the current section – ouch. This I could not copy in QML as the row count of the Model would not match the count of shown entries resulting in wrong height calculations.

So I had to fix the Model and was back doing C++ programming. Now the Model correctly proxies the underlying Model and I can use the standard views in Kickoff as it is also no longer a tree structure. All my work on the tree view in QML was in vain *sigh*.

Last but not least I had to face the recently used Model. Like all the other Models it has a tree structure. After the experience with the Systems Model it was clear to me that I have to rewrite it as well.

After that the last remaining task was to integrate the search and finally a Model which worked exactly the way I expected it to be. Exported the Model to QML, connected the search field and there were search results. Thanks Ivan for the great job of providing a working Model without having to first fix it.

The results of the work look really promising. Kickoff is much faster, all Models are lazy loaded, that is they get only loaded if the tab is selected. So there is no delay any more when clicking the Kickoff button in the panel 🙂

Of course there is still lots of work left for me to train my QML skills. Drag’n’Drop support is missing, context menus are missing. We need some nice animations. But of course there is still lots of time till master opens up.

KWin meets QML

Two years ago I started to re-implement the Window Switching capabilities of the KDE Plasma workspaces (also known as Alt+Tab or TabBox). The old implementation was based on a QWidget with custom painting which of course had some drawbacks. The new TabBox evolved into a framework around Qt’s Model-View concept to design your own window switcher.

Before I started to work on that area I did evaluate the existing Window Switching capabilities of the various desktop shells (both free software and proprietary solutions) and I noticed that all of them have drawbacks. None is the solution where I would say: that’s the perfect switcher.

The main issue is that depending on the user’s habits different work flows are required. A switcher optimized for users with few open windows fails for users with many open windows and vice versa. Especially thumbnails become useless for many open windows.

So I realized that we need something flexible enough to give users the possibility to use different layouts or to even define their own layout. This ended in a framework for window switching. The layout is described with an XML file and rendered through custom painting code in a Qt delegate.

When I implemented this framework I wanted to add a GUI to easily configure own layout. Unfortunately I never got around to implement this UI and I think there has never been any other layout except the default shipped once. It is a rather unknown feature and I’m quite unhappy that this great functionality never got implemented.

In the mean time the trolls did a great job to make UI development easier: QML. This makes it possible to do what I wanted to have for window switching: easy to design and exchangeable layouts. So this weekend I implemented the default (informative) layout in QML and plan to completely replace the existing View and Delegate code in 4.8. And this gives us the possibility to let users write their own layouts and to share and exchange them.

But this is only the beginning of usage of QML in KWin. I have many more ideas by making window thumbnails available to QML UIs in a limited way. This will allow us to even integrate the BoxSwitch effect into the normal window switching framework and replace the Window Strip in Plasma Active.

So great UI times ahead in KWin.