Tag Archives: Effects

Desktop Effects Control Module in KWin5

One of the new features in KWin 5 is a completely rewritten configuration module for our Desktop Effects. In KWin 4 our module was based on KPluginSelector, which is a great widget for a small list of plugins, but it was never a really good solution for the needs of KWin.

Also we noticed that a QWidget based user interface is not flexible enough for what we would like to provide (e.g. preview videos). So when QtQuick came around we had the first experiments with reimplementing the selector with QtQuick, but with the lack of what today is QtQuick Controls it never left the prototype state. But it encouraged us to use one GSoC project on redesigning the control module from scratch and Antonis did a great job there to lay the foundation for what we have now in the upcoming alpha release.

The most noticeable change is that the new control module just focuses on the Desktop Effects. What we learned from our users is that they are only interested in configuring the effects and that the other options exposed in that control module bare the risk of users changing and breaking their system. Thus we decided to give the users what they need and move all other options into another control module.

In order to give the users the possibility to focus on the effects we also did some cleanup in the list and all effects which are not supported by the currently used compositing backend are hidden by default (e.g. OpenGL effects when using XRender). Also all internal or helper effects are hidden by default. These are effects which replace functionality from KWin Core or provide interaction with other elements of the desktop shell. Normally there is no reason for users to change that except if they want to break their system. That’s of course a valid use case and so there is a configuration button to modify the filtering of the list to show also those effects.

Last but not least our effects got extended by information on whether they are mutual exclusive to other effects. For example one would only want to activate the minimize or the magic lamp effect. Both at the same time result in broken animations. For effects in a mutual exclusive group the UI uses radio buttons and manages that only one of the effects can be activated. That’s the change I’m most happy about.

Check out the video to see the new configuration module in action and also see some of the new features I haven’t talked about. Please don’t tell me in the comments about padding issues and rendering problems. We can see those, too, and are quite aware of them. If you want to help iron out issues with Oxygen and QtQuick Controls check have a look to our wiki page.

Screen Cast: Implementing a KWin Effect in JavaScript with Plasmate

I’m proud to present the very first screen cast on how to implement a KWin Effect in JavaScript using current git version of Plasmate. As an example I’m using the new Maximize effect for 4.10. When watching the video, please note that this has been the first screen cast I have ever made ;-)

Direct link to Video.

Tutorials on techbase to be added quite soon.

KWin Effects written in JavaScript

Today I cannot make such a nice announcement as Aaron yesterday, but I can at least try announce something I personally consider as awesome.

This weekend I tried to make it possible to write KWin effects in JavaScript. After about two hours of work the effect loader was adjusted to load a Qt script instead of the library written in C++. This is a quite important step for the future of effects in KWin. It finally makes it possible to share effects via Get Hot New Stuff, so that our users can download new effects directly from the control module.

For packaging effects we use the well established Plasma Package structure, so that our script developers only need to know this one common way. The API itself will share as much as possible with the KWin scripting API – of course with adjustments for effects. For animating the API is based on the AnimationEffect introduced in 4.8.

From a performance point of view using JavaScript does not change anything. Our effect system has two phases: one to react on changes in the window manager (e.g. a window got activated) and one to perform the rendering. The scripting API only interacts with the window manager, so all the rendering is still good old C++ code – a similar approach to QML.

Now I guess you want to know what you can do with it. So here I present for example a Fade like effect written in JavaScript (for comparison: C++ version is > 200 SLOC):

var duration = 250;
effects.windowAdded.connect(function(w) {
    effect.animate(w, Effect.Opacity, duration, 1.0);
});
effects.windowClosed.connect(function(w) {
    effect.animate(w, Effect.Opacity, duration, 0.0, 1.0);
});

For us KWin core developers the scripted effects will be an important step as well. For quite some time we have been unhappy with the fact that there are too many effects which become difficult to maintain – especially if we have to adjust the API. With effects written in JavaScript this becomes much simpler. As we do not have to keep the ABI (API compatibility is enough) stable we can move effects written in JavaScript out of the source tree and make them available for download.

At the moment the JavaScript API is just at the beginning. But I expect it to evolve over the course of the current release cycle. For me the scripts are rather important as it also provides us an easy way to have device specific adjustments.

As I wrote currently the scripts do not operate during the rendering. Because of that we don’t have bindings for WebGL. This would at the moment not make any sense. Nevertheless it might be that we allow to upload custom shaders, but I won’t pursue such a task in the 4.9 cycle.