Plasma Active is an extremely awesome project and I am really looking forward to work on it and have my first own Plasma powered tablet. Of course KWin will be the Compositor and Window Manager in Plasma Active. And this is pretty awesome and very interesting for our future development.

KWin on OpenGL ES 2.0

Plasma Active will probably be the first large installation to make use of our new OpenGL ES 2.0 based compositing backend. In fact OpenGL ES is our primary target because the API is way more advanced than desktop GL and gives better results. Unfortunately the decision whether to use desktop GL or OpenGL ES is a compile time decision. As not all drivers support OpenGL ES on the desktop we still need to default to desktop GL. On Plasma Active we know the driver to be used and therefore can compile against OpenGL ES if supported.

OpenGL ES is far less complex than desktop GL. The desktop stack still carries around the complete outdated and deprecated OpenGL 1.x functionality. It is not surprising that writing a desktop GL driver is difficult. Because of that I expect that the hardware running KWin in Plasma Active will be faster, more energy efficient and magnitudes more stable. It will be the first important step to leave the messy state of OpenGL on Linux behind us.

Different Focus

While Plasma Active still requires a window manager, the superb functionality known from our desktop and netbook shells are not required. By targeting touch screens without keyboards quite some changes to our way of thinking how to manage windows are required. My personal pet Alt+Tab is completely useless on such a device. In order to make it usable we will need to adjust and drop the requirement of holding the "Alt" key. This will of course benefit the desktop users: switching windows could become possible with multi-touch gestures on a touchpad.

Another area of change will occur for window decorations. In fact in Plasma Active there won’t be window decorations – they are just not needed. No, I don’t twist my mind, we won’t introduce client side decorations. We just won’t have decorations. The only relevant button (close) is put into the panel. Also that will need some small tweaking of the KWin source code like many other little advantages we have to make which all will also benefit the desktop.

KWin and the Device Spectrum

Plasma supports the complete Device Spectrum by using custom shells and different QML files for the widgets. Now KWin does not (yet) support the various form factors in such a way. From the window management perspective there is nothing to change. Since the introduction of the netbook shell we know that adjusting KWin just means to change the configuration. KWin already includes all the little tweaks required to have a pleasant experience on systems different to the desktop.

Also in the compositor there is hardly anything to do. We support OpenGL ES and the general compositing doesn’t change just because we run on a gadget. There might be some adjustments required for the drivers as we did not yet have the chance to play with many of them but in general I expect everything to "just work".

The only field which requires adjustments are the effects. Many effects are just not suited for such devices and we will not ship them. In fact I expect that we won’t even allow to customize the window manager and effect system. The danger to harm the system are too high. And some of our effects need adjustments for the use on such a device. Let’s take the Present Windows effect as an example. It allows to close a window when hovering over it. Closing windows from the overview is damn useful (I got the inspiration from Maemo), but hovering is just not possible on a touch device.

In order to properly support both Present Windows on the desktop as well as Present Windows in Plasma Active we need two distinct Present Windows effects. Now writing something like Present Windows is far from trivial. The effect is complex and around 2000 lines of code. We need a better solution for that.

Over the last weeks and months even before I knew about Plasma Active I started to think about how I want to have effects being developed. My aim is that Nuno is not only able to write effects, but that he wants to write the effects. My task is to give him the tools to do so. Over Tokamak next week I will sit down with our QML and JavaScript binding experts to discuss and implement a solution for KWin. A subset of the kwineffects API will be stabilized and be made available for bindings. After lots of thinking I am sure to have found a solution which allows us to write effects in JavaScript and/or QML without spending time in the interpreted part during screen rendering. This will allow us to write effects in a more suited language with the speed of compiled C++ code. The first effect I want to port to the new system will be the Present Windows effect.

In that regard I want to have Plasmate also as a development tool for KWin effects. This will take some time, but I have ideas how we can get previews for the animations and effects outside of KWin. I am both looking forward to implement these parts as well seeing them used.

New Technology for the Desktop

Some of my last blog posts were rather controversial and that was not by chance. I wanted to test out how users will accept the changes which are implied by Wayland. I wanted to see how much acceptance there is for removing features on the Desktop in order to go to a new windowing system. I am very thankful for all the comments I received and that there was some media coverage about these posts. It was very enlightening to read all those articles and comments to them.

My fear that it is not yet acceptable to aim for Wayland was overall confirmed. Especially for KDE it seems that our users do not want us to remove any features. Everything has to be configurable, we "may not go down the GNOME road". For the adoption of Wayland we have a chicken and egg problem: as long as it is not used, applications won’t be ported, as long as applications are not ported it won’t be used. This is similar to what KDE faced in late 2007.

Now Plasma Active gives us new possibilities. Having compositing always enabled is not just a nice thing, it is a requirement which we can fulfill thanks to the advanced drivers compared to the broken state on desktop. We can experiment with moving the screensaver into the compositor without ensuring backwards compatibility. We even do not need to support widgets in screen locker on Plasma Active. This gives us the advantage of first implementing the new functionality and later add the backward compatibility layer for the desktop systems.

And now: Wayland. Wayland is a very interesting technology but it will be difficult to embrace. There is so much depending on X that we have to either port everything and then do the big switch or dare to break functionality. Both is hardly possible on the desktop. Announcements like Mark Shuttleworth’s "Ubuntu 11.10 might use Wayland" do not cause joy in me but fear that it will harm the platform like the too early switch to PulseAudio. Wayland is too important to risk that users think it’s bad because someone just wants to be quick.

Plasma Active on the other hand is a wonderful candidate to embrace Wayland. The stack would significantly benefit from dropping X11 and using Wayland as the windowing system. The driver situation is good: the devices run OpenGL ES 2.0 which is a requirement for Wayland. But most important: we don’t need the window manager. We only need the compositor and effect system – both is basically independent of the X11 stack and can rather easily be made Wayland ready. On Plasma Active we don’t have window decorations, so we don’t need to port them and so on and so on. This gives us a third possible strategy for approaching Wayland: port step by step and use it and do not switch on the desktop before everything is put together. Please don’t over estimate this statement: it is a long road to Wayland and the first release of Plasma Active will not use Wayland. There is lots of work to be done in KWin before we will consider to add support for Wayland. This will most likely not happen in 2011.

How to get involved

KWin can use helping hands. We are only three developers and none of us can work fulltime on KWin. There is enough work to be done for fulltime developers, so we need new blood. Especially after the first support for JavaScript and/or QML is added we need help to get effects written in that language and Plasmate adjusted. These are things I would not want to do. So please get in touch with us either through the mailing list or in one of our IRC channels: #kwin, #plasma or #active are all fine. Please don’t overrun us, we are a small group 😉

=-=-=-=-=

Powered by Blogilo