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
Unit Test Framework for the Window Manager:
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: