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.
Actually, I use Magic Lamp with Minimize effects, because it looks smoother:)
more natural/real “like” effects, similar to natural phenomenons – like crumbling of dirt or flowing of sand/water, emerging of caterpillar, boiling of liquid, evaporation
opening a new instance of a running software- “cell division” from original window.
I don’t think hiding the “Workspace Helper Effects” entirely is a good idea, at least for some of them (e.g. the ones that introduce animations), it’ll just lead more people to just disable compositing entirely. I actually prefer things to be instant rather than animated.
animations are controllable through the global animation speed level. If you don’t like animations just set it to instant and there are no animations.
“forrest gump” like effect with feather, for closing of window, or log out.
It sounds like the effects API needs a place to define an affect “class” (not OOP class, a conceptual class). All effects with a certain class go in a dropdown list where you can only select one of them (or “None”). If there is only one effect in that class, a checkbox next to the class name is shown instead. Effects can be long to as many classes as they like. Standard classes could be defined beforehand, and if a particular 3rd-party class becomes popular you could add it to the list of standard effects. Belong to the special “hidden” class would make the effect not show up in the list.
So you could have a “minimize” class, a “maximize” class, a “desktop switch” class. There would likely be a “window switch” class, which under the hood would be mapped to the “first window switcher” and “second window switcher” classes that would be display in the UI. Similarly, an effect listing the “present windows” class would automatically be given the two window switcher classes as well. Members of the “window open” effect wouid automatically be added to thw “dialog open”, and members of the “window close” efffect would also be included in the corresponding dialog effect (there needed to be a separate effect for dialogs so people could.
If you go this route, I think it would be better to be as liberal as possible with the classes. Sure “explosion” and “fall apart” are intended for closing windows, but someone could conceivably want it for minimization as well. “Sheet” was intended for modal dialogs, but it could be used for window maximization, minimization, opening, or closing as well (although it might be better to get rid of “sheet” entirely and just use “bedropped”).
Having lots of ideas on how to progress is a good thing, but to progress, one also needs focus.
If you could pick only two, which ideas would have the priority?
They are all related to each other. It’s not like there is no focus in it. So I cannot say which is the one with the highest priority. For my development efforts it’s the road to a stable ABI. For other developers I would prefer to see the Unit testing framework to happen.
how about a compiz compability? or a slow migration toward the unification of the two projects?
I don’t see any advantages in that.
I know it might seem boring and not at all related to effects, but is there any chance that you would be able to make resizing a window as smooth as say moving it around ? I have a few machines with Intel, Nvidia and 1 amd/ati and resizing a window on all of them feel very slow and jerky.
Rotating the the desktop on a 3d cube however is flawless 🙂
try the resize effect.
wow thats awesome!
Any idea why a plugin is needed? Why doesn’t the resize work like it did in kde3 ? is this a kwin issue then or is the kwin effect there to fix an issue wit how qt is resizing ?
Solid resizing of windows is jerky/slow because the application has to rearrange it’s controls to match the new size.
Resizing firefox on a blank homepage is fast, resizing it on an heavy page is slow.
I think it is not a matter of window manager.
also drivers influence the experience. E.g. the nvidia blob is known to perform very bad during initial texture from pixmap which happens quite often during resize.
hi Martin,
a few weeks ago I implemented my first kwin effects, but now I realized it is not very feasible to distribute it in a sensical way 🙂
That’s why the following points on the list seem particularly interesting to me:
– Move effects out of KWin: it would be nice if you could install kwin effects using opendesktop services just like you can now for plasma themes etc. I just realize this probably requires the scripting api first (since for plasmoids, this also only works with javascript plasmoids). In any way, if I could just provide an OBS binary which does not have to replace the whole of kwin effects but just adds 1 effect, it would already be a big improvement 😉 of course, if I get lucky, you guys might include it in KDE built-in effects 😉 but supporting 3rd party kwin effects would be very cool imho.
– Standalone Build of the Compositor: a must when developing effects! Currently, I first write my effect using a sandbox app in which I can try out different algorithms and when I’m pleased with the result, I move it to a kwin effect
greets
matthias
In fact you can, by not using the built-in effects library. That is just for bundling all effects. Just have a look in the tests folder containing some other examples.
aha, yes, it works! I managed to put my effect in a separate dir, just like the test effects, but I still have to find out how to build it completely independent from a kwin checkout, as a stand-alone project.
btw, i know this blog is no bug tracker, but I wrote a few mouse locate effects and found out the mouse polling really sucks 🙂
not sure though if it has improved in the meanwhile, since I developed on kde 4.4.4 (will be testing soon on 4.6.2)
I suspect the mouse polling is kind of workaround. Wouldn’t it be great if we could assign a global shortcut to activate an effect, in the same way you can assign global shortcuts to other things?
yes mouse polling sucks and yes you can use normal global shortcuts to activate effects.
.. sorry for my stupid remarks then 🙂
I’ll investigate further how to use the global shortcut.
PKwin with Composite KDE 3.5.x had an option for enabling composite called kcompmgr which was a modified version of xcompmgr it had basic functionality like transparency and fading but nothing else and it wasnt exactly fast.Then Compiz came originally designed by Novell along with XGL but even if it can be used with KDE it obviously was designed with GNOME in mind.The KDE developers wanted eye-candy composite for they KDE 4 series so they had 3 options writing a whole new window manager use compiz or improving kwin they took the last one.That way KDE didnt lose any advance window management feature and won 3D window management full of eye candy and some useful features Present Windows Lets star by one of the useful plugins originally designed by apple it has 3 pesent modes Natural it tries to preserve the size relationship between the different windows Regular Grid Flexible grid Desktop GridFor presenting all the workspaces in a grid in order to make arrangement of windows easier The Legendary CubeCompiz became famous with this I dont think its exactly useful per se but it makes easier for newbies to understand the concept of virtual desktops tough it dont truly work that way XD the point is that it looks good and mixed with the desktop grid can be useful Switchs Alt Tab Kwin has 4 different options for switching between windows that said you can assign key strokes for each one so if you desire it you can use all of themBox switch the most common way of rolling trough windows Flip switch like in Windows Vista whit Aero enabled Cover switch similar to coverflow but with windows And my favorite present windows like expose but using alt-tab The Legendary Wobbly WindowsCompletely useless but most people seem to love the effect I personally dislike it Taskbar Thumbnails On hover shows a miniature of the window ShadowsI found shadows to be one of the most useful effects and it looks good too as you will see in the following screenshot the focus window has a different shadow a pretty nice looking blue shadow Dialog ParentThis plugin dims the window which has an open dialog quite nice looking and it can be useful Dim Inactive Dim Screen for Administrator mode ZoomObviously is for zooming into your desktop quite good for people with vision problems MagnifierZoom with a magnifier its less intrusive than zoom because you can still look at your full desktop as zoom its designed for people with vision problems Track mouseCant you find the pointer? The code is rough at best and its plugins are hard coded to itself not really plugins as much as reduplication of itself Point being it is not easy to turn it into a good window manager and not easy to port or reuse its graphical coolness in anything else.So given that kwin was already a rock solid window manager with many advanced features and a couple of kde hooks to work better with the desktop it was determined that it would be easier to add the little bit of graphical eye candy to kwin that to make compiz any good at managing windows.