QML saved KWin Scripting

Over the last half year I blogged several times that I would drop KWin’s scripting component if nobody takes over the development of the code. Unfortunately up to now we have not seen any improvements. So keeping to my words I would have to drop the code.

Instead I decided to do a last try to get some work done and created some Google Code-In tasks and thanks to that the Tutorial and API documentation got imported to techbase. Example scripts are ready to be imported into kde-examples repository and we have received a KCM for managing the scripts. This is what I consider the minimal requirements for keeping scripting. Without an API documentation it’s just useless.

At the same time I have started to do my planing for the next development cycle. The main task of my work will be in the area of QML (surprise, surprise) with the aim to drop all custom GraphicsView code in KWin and replace it by QML. These are:

• Remaining clean-up of TabBox: Desktop Switching needs to be ported, old code needs to be dropped
• Aurorae is completely GraphicsView based and should be possible to be ported to QML. It will not just be a port of the theme engine, but will allow to write decorations in general using QML. One of the QML based decorations will then be an Aurorae theme interpreter. The long term plan for this is to get it into a state that it can replace the existing decoration API. Will need some time and some work together with Thomas and Fredrik – our decoration experts in KWin. The long term goal is to have it ready for the scene graph in Qt 5 and hopefully be able to integrate this very well with our compositor.
• Desktop Change OSD: rather simple. Help more than welcome 🙂
• Desktop Grid and Present Windows: our effects which use widgets. Now this is the really interesting part of my 4.9 work. Desktop Grid and Present Windows will be ported over to QML and won’t be effects in the classic sense any more. I have been dreaming for years about having effects in a state that our UX designers could do them without hacking C++. Finally we are at the state where this is possible 🙂 As a nice side effect that will make it possible to use Present Windows even without compositing – an idea Lubos told me at my first Akademy in 2008.

All those areas somehow have to access KWin Core and at the moment all have different approaches. Decorations use a “bridge” between the Client’s and their decorations and partially direct function calls.

Effects have an EffectsHandler and EffectsWindow interface representing the Core functionality and working as a proxy. So very similar to the decoration bridge but with much more functionality.

Scripting on the other hand uses a “Wrapper” to export JavaScript functions and calls then the underlying Core objects.

For QML we would have to add Properties to all the functionality which we want to have exported. Which would be the fourth technology and one to many.

Yesterday I started to add the Property definitions to our Client class and ported KWin scripting to use the properties instead of the Wrapper for Client. It breaks existing scripts, but works quite nicely so far 🙂 For me this brings scripting finally in the area where it becomes useable to me: an easy way to test my property definitions.

So we can expect that scripting will get quite some love over the next development cycle. It will be tailored towards my developer needs which will help everyone.

But not only that. Given that we now have the properties, we can also base our Effect system on them. And Thomas did some great work on a generic effect implementation. So expect a second JavaScript API to write effects 🙂

Exiting times are before us simplifying our development work and getting KWin ready for the next big step.

As I expect this to be my last blog post before Christmas I wish everybody a Merry Christmas and relaxing holidays. Thanks for using KWin and all the support I got this year for my work 🙂