Posted on

Continuous Integration for KWin

I decided that the life for my server is too boring as its only used to host this blog and functions as my mail gateway. As the system is rather powerful I decided to setup a Jenkins installation in order to continuously build KWin.

The first step is finished: the kde-workspace repository gets polled regularly and whenever there was a commit to master the sources are rebuild and in case it breaks I will be notified by mail. As KWin is not a standalone project, the complete kde-workspace repository is rebuilt. I want to further improve this process by doing several builds with varying configuration (e.g. the build for Plasma Active) and also for the kwin-wayland branch. But for those I first need to build a recent version of Mesa (no OpenGL ES on Debian Squeeze).
The really useful part of a CI system is that you can also perform some checks on the code. Unfortunately KWin does not yet have any unit tests (it is rather difficult to unit test an X11 Window Manager and OpenGL Compositor), but thanks to our modularisation effort I’m confident that we will soon be able to integrate the first unit tests.
But there are of course other possibilities except running unit tests. So I integrated a cppcheck execution on KWin’s repository as well as setting up Krazy tests, which are unfortunately broken for kde-workspace on quality.kde.org. Due to the lack of automated Krazy runs I have not managed to keep track of the issues lately.
I hope that these efforts help in the long to improve the quality of our software and to ensure that the code doesn’t break with unusual build options especially now when we transit to a major new windowing system.

=-=-=-=-=
Powered by Blogilo

Posted on

Shadow and no Oxygen

All users who do not use our default Oxygen widget style and window decoration might have had an unpleasant surprise after upgrading to 4.7. Our old shadow effect provided generic shadows for all windows no matter which widget style or decoration is used. In case the decoration provided its own shadow that one was preferred.

The new shadow system does not provide any generic shadow. The compositor is just providing a service to the widget style for rendering the shadow. This means that the widget style has to implement support for the new shadows. This has been done at least for Oxygen and Bespin, but it might also be added for other styles – so if you miss your shadows, check whether there is a new version of your preferred style, get in contact with  the author of the style or best of all: provide a patch.
Of course there is also the option to add a generic implementation again to KWin (which seems to be a need), though I must say that I will not spend any time on that myself. Given the experience from our old shadow effect, it is my belief that you cannot have a generic shadow which looks good with all widget styles, windows and color schemes. Nevertheless I am open to patches which add a generic shadow which can be used if decoration and widget style do not provide a shadow. The basic ideas of the new Shadow system are documented in our wiki. If you want to work on it and have questions just get in touch with us through either #kwin or #plasma on freenode or kwin at kde dot org.

=-=-=-=-=
Powered by Blogilo

Posted on

Running KWin with OpenGL ES 2.0

Today we expect the release of the KDE Plasma Workspaces in version 4.7 which is the first release including an OpenGL ES 2.0/EGL backend in KWin. This does not only allow us to run KWin on OpenGL ES powered devices (I am particular looking forward to see KWin on Tegra 2 devices), but also gives us a much better compositing experience on the desktop systems. Thanks to the work on OpenGL ES 2.0 our default compositing backend is now OpenGL 2.x based instead of OpenGL 1.x as it was till 4.6.

I want to thank all users who tested our beta version and release candidates and ensured by that a regression free update. I am very glad on how smooth this major transition of the compositor seems to work according to the very low number of bug reports in this cycle.
On Mesa enabled desktop systems there is also the possibility to go a step further and leave GLX completely behind by compiling KWin for OpenGL ES/EGL only. My personal experience is that it is often a much better experience to use the OpenGL ES build. If you compile KWin from sources ensure that the OpenGL ES 2.0 and EGL development libraries are around and enable the CMake option “KWIN_BUILD_WITH_OPENGLES”. If everything is setup correctly, CMake will tell you “Compiling KWin for mobile”.
Of course compiling from sources is not what most of our users do, so it needs distro help. Thanks to the awesome Kubuntu crew there will be a kwin_gles package available in Kubuntu 11.10. So users can switch to use this package.
But that’s still not perfect as users need to know that there is a better GLES variant. So today I pushed a change to master to build KWin twice: once with OpenGL and once with OpenGL ES. Thanks to our CMake Gods for all the help on getting this done :-). Now if OpenGL ES is available at buildtime a “kwin_gles” binary is compiled and can be used just like “kwin”. For all users of masters, do a git pull, recompile and run: kwin_gles –replace & and enjoy.
And that’s also just an intermediate step. Our GSoC student Arthur is currently working in close collaboration with me on decoupling our compositor from the window manager so that we can build just the compositor once with OpenGL and once with OpenGL ES. We will then put the compositor into a plugin and do a runtime check whether OpenGL ES is working and if it is we will load the OpenGL ES compositor. So if everything works fine, in 4.8 we will be able to offer and default to OpenGL ES 2.0 for most of our users.
This is also important for Phase 1 of Plasma on Wayland, which I will highlight in my talk at the Desktop Summit: Compositing after X – KWin on the road to Wayland. Hope to see you there.
Posted on

KWin Scripting’s Future Depends on You

In last years GSoC scripting capabilities have been added to KWin and have been shipped with 4.6. Unfortunately the student did not stick around so far which results in a situation that during the complete 4.7 releasy cycle there have only been two commits to the scripting component: one to fix some Krazy issues and one to change the coding style. With other words: the development of the component is dead.

For a new component this is very bad as it is unlikely that it is bug free and feature complete. There are probably many usecases where scripting integration might be useful and which is just not yet implemented. It also shows us that the core development team is not able to also maintain this new component. In fact due to lack of provided documentation the core team does not have the knowledge to further extend it.
This unfortunate development raises questions for the future. Currently we have a GSoC to modularize KWin core and it is likely that such a refactoring will break the scripting component at some day. Given that no core developer is knowledged about the scripting component, we are not able to see this in review requests (and we don’t have unit tests for it and cannot add them due to the lack of knowledge about the component). We are also not using the component so we won’t notice a breakage. My expectation for 4.8 is that scripting will be no longer functional and even if bug reports arise we would not be able to fix them.
The GSoC project is preparing KWin core to properly add support for multiple windowing system backends. I have already started to add support for a new windowing system and all the code so far does not integrate scripting. In the far future we want to be able to switch to this new windowing system which has also implications for scripting. Due to the current lack of scripting integration in the new written code it would mean that scripting no longer functions in future.
Overall this does not look good for the scripting component and I am currently considering various options. One of them is to remove scripting support again in 4.8. This is something I don’t want to do and I would feel very bad about it. Lots of work has gone into the code and it is a pity to remove it. Especially given that it was a successfully finished GSoC project and the slot might have been used in a better way for KDE if we remove the code after a year again.
I don’t want to do that! But I need your help to prevent that from happening. Step up and share scripts on kde-apps.org, provide a way to exchange scripts through GHNS, maybe add support for writing scripts to Plasmate and most important get in touch with the development: ensure that the code does not get broken in master, add support for further parts, help to document scripting in techbase, fix some glitches in the scripting related code.
I will keep the code at the moment and look how it evolves over the next months. In case the situation has not improved till soft-feature-freeze of 4.8 I see no other solution than to exclude the code from building 🙁

=-=-=-=-=
Powered by Blogilo

Posted on

Discovering a New World

This weekend a group of KDE hackers met in a small mountain village, Randa, in Switzerland to discuss the future of the KDE Frameworks. I was not present, but started on Saturday an endevour for the future of the KDE Plasma Workspaces. Yesterday evening I arrived in the new world:

desktopgrid-with-wayland
This is not just the Desktop Grid effect. The gears window you can see on each of the desktops is a Wayland client, all other windows are X clients. For me this is a rather historic event, not just for KDE but also and especially for Wayland. Up to now there have only been the demo compositor and the QtCompositor as Wayland Compositors. They are more or less just proof of concept. But this is different event: we have here a normal X11 window manager and are able to integrate Wayland clients into the compositing scene just as if it were an X client. This is not a Wayland compositor, it is a X compositor with an implemented Wayland Server component.
This is the proof that there is a sensible migration path from X11 to Wayland. We can use our normal and known X system and manage Wayland clients in it. There is no need to implement the complete stack on top of Wayland first with possible regression. As we can see the Effect Framework does not need any adjustment to support Wayland Clients, which means we can give the user their known KDE Workspace experience. For the user it is irrelevant if a window is an X or Wayland client, it is just a window. For KDE this means that we don’t need and won’t break the desktop. We will switch to Wayland when we are ready, but at the same time we can offer Wayland to interested developers and users who want to experiment with it. For Plasma Active on the other hand we will switch to an X less Wayland-powered KWin as soon as possible.
Of course there is still a long way to go to get to Wayland. This is just rendering, we still need to implement the complete Window Management, transition the compositing away from X, break out X from KWin and lots more. It’s the result of four days where I spent a few hours each day on hacking on that topic. Which shows how simple the Wayland protocol is, although the documentation could be better 😉
Now the next steps will be to clean up the code, document it and push it into a git branch. I hope to see many developers to pick up on it and to start implementing the window manager functionality and extending e.g. Plasma Desktop to support Wayland Clients in the Tasks Applet and many more such things.
I will present the complete KWin Wayland strategy at Berlin Desktop Summit in August.

=-=-=-=-=
Powered by Blogilo

Posted on

Guest Post: A Hello From KWin GSoC

This is a guest post by my Google Summer of Code student Arthur Arlt.

Hello everyone,

in this very first blog post in my life I first want to introduce myself. Then I 
want to give an overview on my GSoC objectives and say some words about code I 
already produced for KDE’s compositor KWin.
My name is Arthur Arlt. I am studying Applied Computer Science (MSc) at the 
University of Heidelberg. I reached my Bachelor degree at the University of 
Mannheim, where I studied Software- and Internet Technology (BSc). I still 
live in Mannheim and shuttle to the university, since all my friends live here 
and Heidelberg is not that far away (and much more expensive to live, as 
well;).
My GSoC project deals with refactoring KWin’s workspace class. In consequence 
of more than twelve years programming work this class grew to a giant 
‘monster’. Very many functionality was just added to the workspace class 
leading to a header file of almost 1500 lines of code. The objective of my GSoC 
project is to refactor this one big class, structuring the functionalities to 
reasonable own classes as modules. On the fly it is possible to rename 
variables and functions to follow a consistent naming scheme.
Doing all this is not only just for fun. The main reason for the 
modularization of KWin is to ease the port to Wayland. Also some 
functionalities are not required for special devices like tablet PCs. E.g. the 
functionality of screen edge handling is not needed for devices controlled by 
touchscreen.
In the past three month I started to code some peanuts for KWin. The first idea 
I had was to extend the quick tiling feature with tiling to quarters. My 
mentor Martin Gräßlin showed me where the changes have to take place and I got 
my first feature implemented 🙂 As a foretaste of my GSoC I moved the outline 
functionality to an own class. This made it possible to easily write an effect 
for outlining windows and replace the old X implementation.
My first GSoC step was to remove the non-working functionality of TopMenu. As 
replacement we now have Kubuntu’s AppMenu. The second step I am currently 
working on is to break out the TabBox (Alt+TAB) from workspace to an own 
class.


Cheers!

=-=-=-=-=
Powered by Blogilo

Posted on

The Compositing Modes of KDE Plasma Workspaces Explained

In the KDE Plasma Workspaces 4.7 we introduce new Compositing backends/modes in our Compositor. Lately I noticed that there is some misunderstanding on what are the differences between the modes, why we wrote new code and what is the best mode for whom (at least one distribution did it wrong in their first packaging approach). With this blog post I hope to shed light on the various modes.

OpenGL 2.x/GLX

This is our default compositing backend. It uses only the so-called programmable pipeline or also known as the “core” profile. For rendering we use only shaders written in the OpenGL Shading Language (GLSL) without making use of any fixed-functionality emulation code. For the interaction with the underlying graphics system we use GLX and the extensions for compositing. Namely the texture from pixmap extension to get an OpenGL texture from an XPixmap (the window content). As the code matches the core profile it would be easy to add “support” for OpenGL 3 or 4, just in case someone is wondering. But as we do not make use of anything provided by OpenGL 3, there is no need for this.

OpenGL 1.x/GLX

This is our legacy backend and the code we only had in 4.6 and before. The code uses only fixed functionality. Up to 4.6 it was possible to also use Shaders written in GLSL. This is no longer possible. Effects requering shaders may provide a shader using the ARB Shader extension which can be used only in this mode. The code to access the underlying graphics system is shared with the OpenGL 2.x backend.
The legacy backend is used automatically for all drivers not supporting at least OpenGL 2.0 and the fglrx driver. Furthermore there is an option to enforce this mode in the Advanced Desktop Effect settings: uncheck option “Use OpenGL 2 Shaders”.

OpenGL ES 2.0/EGL

This is the backend for the future. It’s primary target are mobile devices (Plasma Active), but also on the desktop it is very important as it is the requirement for supporting Wayland. Like OpenGL 2.x it uses the programmable pipeline and shaders written in GLSL. In fact the OpenGL ES 2.0 and OpenGL 2.x backend are identical to more than ~ 95 %. The difference is in the way how to access the underlying graphics system. Instead of GLX we use EGL and the EGL_KHR_image_pixmap to bind an XPixmap (window content) to an OpenGL texture.
In opposite to the other two OpenGL backends this one is not a runtime option, but a compile time option. OpenGL ES 2.0 is (mostly) a subset of OpenGL 2.0 without the legacy code. So the old code would simply not compile against the libraries and that’s why it is a compile time option. To enable use the CMake flag “KWIN_BUILD_WITH_OPENGLES”. Be aware that EGL is not supported by all drivers. To my knowledge only the Gallium radeon and nouveau drivers support it at the moment. This means especially for distributions: don’t use the build flag for the default package, but provide an additional one. For the next release cycle I hope to make it a runtime option.

XRender

XRender is a completely different backend. It can be selected in the advanced Desktop Effect settings in the dropdown “Compositing type”. Furthermore it is used as a fallback when the OpenGL backend fails in an expected way (e.g. Software Rasterizer). The XRender backend can only provide 2D animations, so e.g. no Cube effect. Performance on the backend depends on the driver, but can be rather fair (I once did not notice that the XRender backend was used in a virtual machine).

No Compositing

Not really a backend, but also a mode which has to be mentioned. KWin also supports no compositing at all. This mode can be entered at all time by the Shortcut Alt+Shift+F12 and in the General Desktop Effects settings through option “Enable desktop effects at startup”. Also at runtime self checks may disable compositing and also applications can block compositing bringing KWin into this mode. The Composited mode can be re-enabled through the same shortcut.

How To Notice which one is Used?

This can be quite tricky, because KWin automatically falls back to a different backend if one fails. E.g. if OpenGL 2 is not available OpenGL 1 is used. Or if OpenGL fails, KWin might fall back to XRender. KWin does nowhere log which backend is really used, but there are some messages printed to stdout which can help recognizing the version. KWin always prints out the used OpenGL version information. This looks for OpenGL like this:

OpenGL vendor string:                   Advanced Micro Devices, Inc.
OpenGL renderer string:                 Mesa DRI R600 (RV710 954F) 20090101 TCL DRI2
OpenGL version string:                  2.1 Mesa 7.10.2
OpenGL shading language version string: 1.20
Driver:                                 R600C
GPU class:                              R700
OpenGL version:                         2.1
GLSL version:                           1.20
Mesa version:                           7.10.2
X server version:                       1.10.1
Linux kernel version:                   2.6.38
Direct rendering:                       yes
Requires strict binding:                no
GLSL shaders:                           yes
Texture NPOT support:                   yes

And for OpenGL ES:

OpenGL vendor string:                   X.Org
OpenGL renderer string:                 Gallium 0.4 on AMD RV710
OpenGL version string:                  OpenGL ES 2.0 Mesa 7.10.2
OpenGL shading language version string: OpenGL ES GLSL ES 1.0.16
Driver:                                 R600G
GPU class:                              R700
OpenGL version:                         2.0
GLSL version:                           1.0.16
Mesa version:                           7.10.2
X server version:                       1.10.1
Linux kernel version:                   2.6.38
Direct rendering:                       yes
Requires strict binding:                yes
GLSL shaders:                           yes
Texture NPOT support:                   yes


To distinguish OpenGL 1 from OpenGL 2 backend there is one debug message related to "KWin::ShaderManager::initShaders". There should be three messages for valid - then OpenGL 2 is used or at least one message on failure, then OpenGL 1 is used. Recognizing XRender is even more difficult. In case that we face issues for debugging we will add more precise debug messages. Personally I test which backend is used by using functionality tests: the Cube Effect requires at least OpenGL and the Sphere and Cylinder effects require at least OpenGL 2.




Why a new Backend?


There are several reasons why I started to work on the OpenGL 2/OpenGL ES 2.0 backend. First of all we wanted to have support for everything which is nowadays known as Plasma Active, but also Wayland is very important on the longer term. Currently Wayland requires an EGL backend, so having support for EGL is a prerequisite. Last but not least to give our users the best possible performance and user experience. The programmable pipeline is a way nicer API to write GL code and especially the ES code can benefit users as it throws out all the legacy code and state tracking, which is rather complex in OpenGL and should ensure better drivers.




=-=-=-=-=
Powered by Blogilo
Posted on

Plasma Compositor and Window Manager in 4.7

With the first Beta for KDE Plasma Workspaces 4.7 out of the door it is time to look back what we achieved in the last half year for the KDE Plasma Compositor and Window Manager. Personally I think this will become a very great release with hughe improvements for our users. The best about it is, that users should not even notice that anything changed at all. Almost everything we did is under the hood improving performance, stability and rendering.

Programmable Pipeline

The Compositor received a new OpenGL compositor based on OpenGL 2.x or OpenGL ES 2.0. Our default rendering nowadays uses the programmable pipeline instead of fixed functionality as in 4.6. In order to support the programmable pipeline quite some parts had to be rewritten and got optimized at the same time. Overall this brings a vast performance improvement for all users. From my experience this can even be increased when using the OpenGL ES 2.0/EGL backend which is unfortunately a compile-time switch (as not all drivers and hardware support EGL). I hope that distributions will provide an additional package.
As with all such changes there is the chance that on some hardware/driver combinations the performance decreases due to the raise of requirements to OpenGL 2. If that is the case the user can switch back to the legacy rendering mode by unchecking the option “Use OpenGL 2 Shaders” in the advanced Desktop Effects settings. This will disable all GLSL Shaders. Nevertheless Blur and Lanczos are still useable as they will fallback to ARB Shaders.

Blur Effect

Fredrik has done some great work to improve the performance of the blur effect. Effects can know recommend whether they should be enabled by default and for Intel hardware, the effect does not get enabled any more by default. Users can still manually enable the effect. But there is also some real optimization to ensure that less screen estate gets blurred in each rendered frame and some optimizations on the shader giving a ~60 % improvement in shader performance with R600G.

Blocking Compositing

Thomas worked on a way to allow applications to block compositing. The primary goal is to have video players or OpenGL Fullscreen games be able to block compositing as for such use cases compositing is only a bad overhead. We have heard interest from VLC and Wine to support this new flag, but users  can even make use of it if the application does not yet provide support for it by using a window specific rule. Given that we have now this new way to suppress compositing we disabled the unredirection of fullscreen windows by default.

New Shadows

Together with Jacopo, Hugo and Aaron we worked on adding a new Shadow system allowing to provide their own shadows. This is currently used by Oxygen Qt and GTK to render shadows for so-called unmanaged windows. As the control for the look is with the client, the widget style is able to adjust the shadows for e.g. Mozilla Firefox. Also Plasma is making use of the new Shadows for the Panel and KRunner fixing some annoying issues with the old implementation like window snapping to the panel shadow and clickable shadows in KRunner. Not to mention that the new shadows look way better 🙂 Special thanks to Jacopo for writing the XRender code for the new Shadow system.

Outline

Arthur, our GSoC student, did some refactoring already before the GSoC project and brought all outline related code together in one class. This allowed me to add a new Effect to render the outline using a nice looking Plasma FrameSvg. If effects are not active the old X11 code is used. I am looking forward to Arthur’s GSoC, what I have seen so far looks very promising.

Graphicssystem Raster

Very short before the release we received a Patch from a new contributor, Philipp, allowing KWin to support the graphicssystem raster. Before KWin enforced the native system. In the beginning I was reluctant to integrate it, but got convinced that this is a hughe improvement. Especially with the NVIDIA blob this is a nice addition as we circumvent the slow transparent filling of XPixmaps improving the performance of resizing windows (caused by decorations) and the effect frames in e.g. Present Windows effect. There are more improvments to come from Philipp like a heap optimization for glibc in KWin, scheduled for 4.8.
And of course much, much more happened which I just don’t remember at the moment 🙂 And for the next release cycle we can expect more great things to happen, more about that on Desktop Summit.

=-=-=-=-=
Powered by Blogilo

Posted on

On Stability

KWin has been known as a rock-solid window manager in the KDE 3.5 times. I was wondering how the situation is nowadays with focus no longer on window managing but on compositing. Currently we are experiencing a major problem in combination of Intel/Mesa drivers with either fullscreen flash videos or OpenGL screensavers. Since the release of Kubuntu Natty we receive two to three new duplicates each day. In case you are experiencing this issue: do not report! Neither to us, nor to Mesa nor to (K)Ubuntu. It is a known issue and Upstream is working on a fix! As a workaround, do not use Flash to watch Youtube videos and do not use OpenGL screensavers. The issue is the most often reported bug against KWin of all time, now.

The fact that we receive duplicates for an issue clearly recognized by DrKonqui as already reported multiple times can tell us a lot about other problems. If we have a real stability issue we receive many bug reports and we have seen this in the past. Apart from the noise of mentioned crash above we have hardly received any new issue lately, so I thought about going through all our crash reports to get an overview of our current stability. I am also a KWin user and cannot remember a single KWin crash at work with openSUSE 11.4.
After todays and yesterdays triaging there are less than 20 open crash reports and I am only able to reproduce one of them and fixed another one. Most of our previously open crash reports have not seen any activity over the last year(s). Many of them had been reported against 4.4 or an even older release without duplicates of newer versions. All those have been closed, given that we most likely fixed these issue. Many thanks to Thomas for fighting crashers in various effects and the window grouping functionality. (Keeping the crash reports open does not make any sense as there have been too many code changes to make any use of old crash reports.)
The remaining open issues which I am not able to reproduce are in most cases missing a description how to reproduce, so it is very unlikely that these affect our users and it is possible that they are already fixed. Given this, I am happy to say, that also as a compositor KWin is rock-solid 🙂

=-=-=-=-=
Powered by Blogilo

Posted on

KWin and Plasma Active

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