Now with the GSoC application timeline ended, I feel like blogging about some more ideas what I want to see in KWin in our next releases, but are not enough for a GSoC. Nevertheless most of it is in the scope that it can also be handled by new developers. But some parts have to be done by KWin/Plasma developers.

Stable kwineffects ABI:

This is one of the most important pre-requisites for the other ideas. KWin currently has no stable effects ABI and it is rather difficult to get it stable as it would become almost impossible to extend the API in future. Up to now this has never been a real issue as KWin includes (almost) all existing effects – the only effects on kde-look are from KWin developers knowing about the situation. Nevertheless last year we had to face for the first time the situation that an effect was proposed for inclusion which did not fit our own goals. For 4.7 I have already done a great deal on getting the kwineffects library into a state that makes it easier to provide a stable ABI and I want to do another round of changes till 4.7, but due to the size of the library it will not be possible to provide a stable ABI before 4.8.

Move effects out of KWin:

KWin has a large amount of effects which are not really usable. Here I have also to look at myself, because I implemented some effects I nowadays consider as useless. Now I don’t want to remove features and I don’t want to just drop the code. We need to define a set of effects which we want to ship and move the remaining effects either to kdeplasma-addons or to extragear. This would allow us to concentrate more on the effects which improve the user experience than just adding eye-candy. Of course this change requires that the kwineffects ABI is stable. For this task new developers can help by writing up a proposal on which effects to move and how to group them.

Define the Workspace Helper Effects:

KWin has a set of effects which are helper effects for either the Plasma workspace or KWin core itself. Examples for the Workspace integration is the Dashboard effect or sliding windows. For KWin core there is the resize effect or window geometry. Now these effects are really important as they are mostly hughe optimizations over the existing X11 code base. There is no reason at all to have them in the UI and to make it possible for the user to disable them. For this a new effect group has to be defined which is not presented in the effect selection. On the other hand at least the dashboard effect has a config UI and this needs to be accessable. So it needs to be moved somewhere where it fits better.

Better Effects Configuration Module:

KWin uses KPluginSelector to provide access to the configuration of all effects. The plugin selector is a nice tool but not made for the requirements of KWin. We have effects which do not work together – for example it does not make sense to use minimize and magic lamp effect at the same time. Such groups of effects cannot be modelled with the current solution. It would be nice to have a real UI to configure the effects and to provide more information about all the effects than what is currently provided. If I were a user I would be lost in this UI 🙁

JavaScript bindings for effects:

As soon as the ABI is stabilized I want to have the possibility to write effects in an easier way than C++ code that is JavaScript. Of course the current API is not very useable for that as the interpreted code would be called up to 60 times per second. I am currently working on a new additional Effect API which would allow to have the often called parts in normal C++ code and only the window/effect system interaction in JavaScript. I hope to have the foundation for that ready at the time of the beginning of the next release cylce. Help is welcome on exporting the methods to JavaScript and providing the required interaction as I personally have no idea about it 😉

Unit Test Framework for the Window Manager: I would like to be able to properly test the window manager so that we don’t see regressions. Testing a window manager is non-trivial as it requires interaction with X11. My idea is to load KWin in a Xephyr environment and execute tests written in JavaScript and using KWin’s scripting interface. Having such a test environment would allow to properly define tests for all window manager functionality and ensure the regression free transition towards Wayland.

Standalone Build of the Compositor:

Being able to just build the compositor and run it in a window would give us quite some new possibilities. We would be able to develop without constantly restarting the window manager and to properly debug it. Furthermore we could execute the effects in the standalone application and compare rendering results against pre-rendered images and by that having a set of unit tests for us and the driver developers. The optimum would be if the complete compositor and effect system could be integrated into the piglit test suite.

“IDE” for Effects:

With the standalone compositor and the JavaScript bindings it should be possible to develop effects in a way like developing Plasma Applets with Plasmate. I would like to have something were you can just specify “move window from here to there” and maybe define an additional OpenGL shader to animate the window. As all of it is interpreted code it should be possible to see the results instant and with that giving our designers a better tool to define the effects we want to have in our Plasma workspaces.