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:
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.
Is the intention to let apps request KWin to do stuff, or purely the end user.
For example, could I add some code into the chat window from KDE Telepathy to alter the shadow colour based on whether there is an unread message to highlight it, or is that a misuse of the point of this?
Apps are not allowed to use scripting. This would be a clear misuse.
on the other hand, this level of scripting even inside apps would be very interesting for purpose of customizing UI…
apps should not adjust towards one specific window manager or even change the configuration of this one. If they try to do so, something is clearly wrong. In general there is the proper way to do things and that works then for all window managers. So using KWin scripts is just a workaround for the real problem.
Hi Martin,
thanks a lot for improving KWin! I’m looking forward to the 4.8 and of course the 4.9 release of KWin. Keep up the good work!
Still very happy that scripting won’t be dropped, and is in fact being improved.
My personal use case for scripting is toggling the “Keep Above” bit on a window depending on whether it is maximized or not, which is ideal for my video player: When I maximize it it shouldn’t simultaneously stay on top, so I can still Alt-Tab to other windows. But when not maximized, I want it to stay on top.
This was possible with the first generation of kwin scripting already, but unreliable at times. I’m sure it’ll now work perfectly.
it is a nice example, that I will try to include into my test scripts.
Ist dadurch auch so etwas möglich: http://noughmad.files.wordpress.com/2011/12/appmenu-oxygen.png
The question is whether window decorations supporting the app menu become possible.
This has nothing to do with the functionality required for app menu support. As the screenshot illustrates this is already possible for window decorations.