Posted on

The Costs of Supporting Legacy Hardware

The interesting IT news of last week is probably that the next Mac OS X version will drop support for some legacy hardware. Looking back at the history of Apple we see that this is not the first time, but that the company dropped support for old hardware quite regularly by changing the CPU architecture. This time it is different as the GPU is the reason for the drop of support.

This made me wonder what are actually the costs to support legacy hardware in KWin? While it is completely acceptable that new Windows versions and new Mac OS X versions do not run on legacy hardware, there seems to be the demand that free software has to support all kind of legacy hardware. So what does supporting legacy hardware cost for KWin?

What’s important to remember when asking this question is that supporting legacy hardware has nothing to do with supporting low end hardware. That is supporting OpenGL ES 2.0 hardware is in fact an improvement as most of the code is shared with the OpenGL 2 backend, but supporting OpenGL 1.x hardware really requires different code paths. So optimizing for low end hardware improves the overall system while optimizing the legacy hardware might in fact decrease the quality of the overall system.

So what is the legacy hardware we are facing with KWin? Well basically anything not supporting at least OpenGL 2.0 and not supporting non-power-of-two (NPOT) textures. The latter ones are really causing headaches as we are unable to develop for it and have broken support for it during the last release cycles.

Up until recently Mesa did not support OpenGL 2, but this is nowadays no problem any more, so we can be sure that if OpenGL 2 is not supported, the hardware is lacking features. On ATI/AMD OpenGL 2 has been supported since the R300 (with limitations in NPOT support) which got released in 2002. On NVIDIA OpenGL 2 has been supported since NV40 which got released in 2004. On Intel OpenGL 2 has been supported since I965 which got released in 2006. (All this information is taken from KWin code)

This means if I talk of legacy hardware it means hardware which is at least six years old. Supporting such hardware comes with some costs. E.g. on Intel you have the problem that you cannot buy the GPUs, that is you have to get a six year old system just to test. With ATI I faced the problem that even if I wanted to test an old R200 I cannot install it in my system because my system does not come with an AGP socket anymore – the same holds true for old NVIDIA systems.

So the only possible solution to test on real hardware which is not OpenGL 2 capable means to use hardware as old as the GPU to test. As there is the saying that free software development is about “scratching his own itch”, I must admit that I cannot scratch any itch with running legacy hardware. Especially not when I want to develop. I have a rather powerful system to not have to wait for compile jobs to finish. Developing on a several year old single core system with maybe a gigabyte of RAM is nothing I want to do.

So in fact we cannot develop for the legacy hardware. Now let’s have a look at the costs for us to have legacy hardware support. In KWin this comes as the OpenGL 1.x backend and to a certain degree also as the XRender backend. XRender has a some usefulness without considering legacy hardware as it provides translucency for virtual systems. Nevertheless we should consider it as a legacy support system. According to SLOCCount the XRender backend has a size of about 1000 lines of code. But I can only count the discrete source files for XRender. It does not consider the branches in other code pathes and so on.

Getting an overview of the OpenGL 1.x related code is rather difficult. SLOCCount cannot help as the code just uses different code branches in the same files. Looking at the code it is clear that there are several hundred lines of code dedicated to OpenGL 1.x. This is unfortunately also scattered around many files. Overall about 5 % of our core code base  is dedicated for supporting legacy hardware. All OpenGL 1.x related code is also ifdefed to hide it from the gles backends. So each dedicated OpenGL 1.x call comes with an additional ifdef and in many effects there is a branch for OpenGL 1 and for OpenGL 2.

To sum it up: we have increased complexity, increased maintenance costs and lots of code just for OpenGL 1.x related hardware which we cannot really test. So a rather bad situation. Additionally it is nothing which we can continue to support in the future. Neither Wayland nor Qt 5 will make sense on such hardware (XRender based compositing might still make sense with Qt 5, but as the name says not with Wayland).

Given this the logical step would be to remove the OpenGL 1.x related code completely. This would of course clash with the demand of some user groups thinking we have to run on old legacy hardware. In the case of Intel GPUs it might be in fact true that there is still a larger number of users around – this is of course difficult to judge.

Another real issue for removing is that the proprietary ATI driver (aka Catalyst/fglrx) only provides a decent compositing performance with indirect rendering restricting the available API to OpenGL 1.x. So removing OpenGL 1.x support would mean removing OpenGL compositing support for all fglrx powered systems even if the GPU supports OpenGL 4. But to be honest: given that the radeon driver has no problems with OpenGL 2 on the same hardware, I would not mind removing support for proprietary drivers.

What might be a nice solution to this problem are the llvmpipe drivers in Mesa which hopefully provide a good enough experience without hardware support. At least Fedora wants to use llvmpipe drivers for GNOME Shell. As soon as Mesa 8.0 hits my Debian testing system I will evaluate the usage of llvmpipe drivers for KWin as this will hopefully improve our experience on virtual machines. If I am satisfied with the performance, I will be tempted to remove the OpenGL 1.x based legacy code…

Posted on

Enabling Others to do Awesome

Recently Aaron wrote a blog series for the introduction of Spark, I want to cite a central saying of one post:

I want the things which I help make to become opportunities for others in their turn to participate with their own voice, their own movement and their own passion.

If I reflect my own motivation for my work on KWin and especially the areas of work I decided to work on in the 4.9 cycle I see quite some parallels to the paragraph cited above. But personally I would phrase it slightly different:

I want to help others to do awesome.

This describes perfectly what I am currently working on. I no longer want to write fancy effects – in fact I stopped adding effects quite some time ago. I don’t want to extend KWin to be the window manager which incorporates all other window manager concepts no matter how useful they are – we stopped doing that as well.

But still I want that our users get the window manager they want. Whether it is fancy effects or a tiling window manager or new concepts for virtual desktops, KWin should be the base for it.

At the heart of all these efforts we have the scripting bindings. While we already had bindings since 4.6 they never really got used – this will change 🙂 But JavaScript bindings is just one part of the game, the other part is declarative, that is QML, bindings.

In 4.8 we already experimented with QML for the window switcher layouts to test whether QML fits our needs and I am very happy so far with it. But 4.8 does not yet include the possibility to really write own layouts. While it is possible to do so, there is no way to configure a custom one or even distribute this.

For 4.9 the installation of the window switcher has been adjusted to use the Plasma Package structure which makes it possible to install window switcher through the plasmapkg tool. But this is only part of it: plasmapkg has been extended to support any kind of scriptable KWin content, be it window switchers, KWin scripts or KWin effects written in JavaScript (decoration to be added soon).

For this KWin scripts follow also the Plasma Package structure which is quite awesome as it finally allows to dynamically enable/disable scripts through our KCM:

This dialog wants to tell me: “I want Get Hot New Stuff integration” to directly download new scripts from the Internet. And sure it does need that and this will be added for the 4.9 release.

The screenshot shows two scripts I’m currently working on – both will be shipped with KWin in 4.9. Videowall is a script which scales fullscreen video players over all attached screens to generate a video wall. This is the first script which actually replaces functionality from KWin core. KWin had the functionality to disable multiscreen support for fullscreen windows and that really cluttered both code and UI. And it just did not make any sense. There are just no valid usecases to have in general fullscreen windows span all screens, except for video walls. And that’s what we have here: a small KWin script to make an obsoleted functionality sane. We improved KWin for everyone by removing an difficult and confusing control module without taking away the functionality for expert users.

But even more interesting than the video wall is the other script. This is not a JavaScript based KWin script, but a declarative QML script. It will replace the existing C++ based implementation of the desktop change OSD without any functionality loss. Which means less code and much more readable code 🙂

And what’s really awesome: JavaScript and QML have the same bindings, the API is exactly the same. So going from QML to JavaScript and vice versa is extremely simple. But that’s not all with QML based KWin scripts you can include live window thumbnails. So this is a technology to allow you to do awesome new switchers like Present Windows or Desktop Grid.

As you notice I’m currently dogfooding the bindings to myself. This helps me to see what is needed, what can be improved and to ensure that the bindings will work for any given usecase we can imagine. My wish is to see for example the complete window tiling support in KWin to be rewritten as a KWin script. This should be possible and would proof that you can use scripting to get a completely different window management.

So if you want to make awesome things with your window manager, now is the time to get started. Don’t hesitate to contact me and demand further bindings if anything is missing.

Disclaimer: QML support has not yet been merged into master.

Posted on

Having a look at the old/new Desktop Environments

2011 seems to have finally been the year of the Linux Desktop. But not in the way people always anticipated it by Linux Desktops finally dominating the desktop market (something which will probably never happen unless Microsoft fails badly), but by releasing many new Desktop Shells.

Both large desktop communities have introduced a new shell. The GNOME community has released GNOME Shell, the KDE community released the touch oriented Plasma Active and Canonical decided to go alone with Unity. All these shells introduce new User Interaction concepts and interestingly 2011 was also the year of new classic desktops.

GNOME 2 got forked as the Mate Desktop, GNOME Shell got forked as Cinnamon to provide a classic user experience. In the Qt/KDE world Razor-Qt got introduced and although being around a little bit longer Trinity (a fork of KDE 3.5) got some attention probably based on the fact of the forks of GNOME.

My personal expectation is that Mate will fade away due to Cinnamon. For Cinnamon I expect that it will stay as there seems to be a demand for a classic desktop experience in the GNOME world (btw Plasma could do all that for you). My hope is that Cinnamon and GNOME Shell will rejoin again as I don’t like forks. GNOME Shell will of course also stay around and I expect it to become quite successful as time passes by and I expect many former Ubuntu users migrating to it when Canonical finally decides to go for Tablets only.

Trinity – Who needs it?

In the KDE world I find the Trinity project most interesting both from a social and from a technical point of view. I am very interested in understanding why developers decide to keep an outdated and orphaned code base alive. What motivates the developers to continue the development given that the original authors moved on? Also what are the targeted user groups? Who needs an outdated system like Trinity? I tried to identify the possible user groups of Trinity and came up with three groups:

  1. Users searching for a “lightweight” desktop
  2. Haters of “KDE 4” technology
  3. Users wanting a “classic” desktop on KDE

The first user group mostly confuses lightweight with old hardware. If we see the specs of Spark I would not call that a high end system, so the reason that users have trouble with KDE Plasma on “lightweight” systems is not because the hardware is “lightweight” but just old. But even KDE 3.5 was far from lightweight. The saying that KDE is bloated is probably as old as KDE itself. So the users looking for Trinity as a lightweight alternative to KDE Plasma just fail to realize that five years ago they were screaming that KDE 3.5 is too heavy. Neither KDE 3.5 nor Plasma tried to run well on old hardware – this is a market very well served by e.g. LXDE. So keeping KDE 3.5 alive for such users seems to be the wrong decision.

The second user group is the most dangerous to the project. My fear is that the project gets dominated by users and developers hating the KDE 4 technology. Emotions – especially hate – are very bad to base decisions on. If better technical solutions are discarded just because it might optionally pull in a “hated” KDE technology, the project will run into problems. Also if the hating user group is too big it brings the danger that they will block any progress of the project by proclaiming that they will leave (hate) the project as well. The result would be stagnation and a backward oriented project. My personal opinion is that Trinity is already dominated by haters – more to that later on.

The last user group is the one demanding a “classic” desktop. Well this seems like a valid use case to me. But if I look at a recent KDE Plasma 4.8 and at a KDE 3.5 I don’t see much difference. With a few clicks you get a desktop which looks and behaves the same way as 3.5. There might be slight differences, but is that worth keeping millions of outdated lines of code alive? Wouldn’t it be better to just write another Plasma shell to mimic the KDesktop/Kicker behavior? And even if you don’t want a Plasma powered classic desktop, there is Razor-Qt which offers a modern approach to the problem instead of building on legacy solutions like Trinity.

Trinity – the desktop of duplication

One of the biggest issues with the development of Trinity is that they took over the KDE 3.5 code base without having a plan what to do with it. There are applications which got dropped in KDE 4 (e.g. Kicker) – for those I can understand that the development is continued. There are applications which use a “hated” technology – e.g. KDEPIM using Akonadi. Unfortunately continuing KDEPIM 3.5 will not solve any of the issues which lead to the hated technology nor will it improve the modern project. Last but not least there are application whose development continued in the same way offering a much better product nowadays – for example KWin, Kate, Okular or all the games and edu applications. For those applications I don’t see any need to continue the development of the KDE 3.5 product: it does not serve any of the identified user groups. Personally I find it very sad to see valuable FLOSS developer power wasted on such products instead of helping the current versions.

This is an unfortunate duplication of work. But it’s not the only one going on in the Trinity project. They migrated to git – again (KDE already did that). They migrated to CMake – again (KDE already did that). They started porting to Qt 4 – again (KDE already did that). They have to migrate away from HAL – again (KDE already did that). It’s a pity to see all this duplication with that limited manpower.

But it’s not only the duplication which is a real issue, but also the lack of knowing what is going on in KDE. For example there is an enterprise branch of KDEPIM 3.5. I just dared to pick out one random commit from KDE’s enterprise branch and checked whether the change is present in Trinity’s version of the changed file. I think you can guess the result. I also checked one random change for kdelibs and that is also not present in “tdelibs”. Monitoring directories for changes is extremely simple in KDE.

This means that Trinity does not only duplicate the work already done by KDE, but also that a user running Trinity gets a worse product than stock KDE 3.5 as offered by some distributions using the enterprise branches.

Trinity – the haters desktop

Some time ago I decided to contact the Trinity development team with the aim to reduce some of the ongoing duplication. Seeing commits to “twin” really hurts and our current version of KWin is just better in any area. We have not just integrated compositing but also fixed many, many window manager related bugs. All those fixes are not present in the “twin” fork.

But there is a more dangerous issue. I had taken the time to look through the commits to “twin” and they are in the categories from “plain wrong” to “might lead to a crash that twin does not start any more”. Developing on a foreign code base without any help is very difficult and nobody has ever contacted the kwin development team before (at least not me personally, the kwin mailing list, the bug tracker, the IRC channel when I was around).

The reactions to my offer to help were mostly (there are a few positive exceptions) negative. And unfortunately it resulted again in duplication of work. The lead developer decided that it is important to allow multiple window managers. This is a great thing to do, but what a pity that the KDE developers thought about the same years ago and found a better place to put it instead of the window decorations KCM.

But I wanted to write about the hatred. One of the reactions to my proposal was:

Personally I would hate to have to install kwin, which relies on a bunch of other KDE4 libraries and automatically installs that akodani garbage scanner stuff, just to use TDE

After pointing out that KWin does not depend on Akonadi, I got:

I meant nepomuk, not akodanai.

I think especially the typos speak for itself. Not knowing what the technology is, what it does or what it is for. But obviously it is a “garbage scanner”. This is not a random developer or user, but the project leader.

Another highlight of a recent thread:

This is another area that we should be able to do better than KDE4

Where I ask myself why would anyone have that aim at all? Why not work together with KDE to have a shared and improved code base? After pointing that out, I was informed, that

This Email was not supposed to go to the public list

We see here unfortunately a pattern and I dare to quote another mail from the same thread:

I don’t have time or the desire to pick through KDE4 at the moment but KDE4 is still less efficient for my workflows then TDE, period. It takes more space on the screen to display less information in a harder-to-digest format for starters. Then there is the whole assumption that people have low-resolution or small screens and one-button mice (in TDE all three mouse buttons can be used to interact with on screen elements–much of that power is just gone in KDE4).

As I said I don’t have time to play with KDE4, and all of my prior attempts to use KDE4 as anything other than a shiny toy failed miserably. Please remember that there is a bit of a frog-in-the-pot syndrome when users are forced to use an inefficient interface for long periods of time; the best way to break this is to go back and use Windows XP or KDE 3.5 for a day or two, then go back to KDE4. If KDE4 is truly better then that will be obvious; if it is not then this fact will also be obvious. (I have done this and KDE4 still looks like a shiny toy).

I recommend to read this paragraph several times. Let it sick in…

… thanks. Now let’s see: someone claims that KDE 4 (probably Plasma) is still less efficient, although he did not test it. This person is in charge of the development of Trinity. How should he be doing any sane decision with such a world view? I don’t get it.

It’s pure hatred against KDE technologies and this dominates the development of Trinity. And this is not a single developer issue, it’s unfortunately a common pattern. I have for that one more mail to point to (only click the link if you have not eaten anything and prepared a bucket next to your seat). The worst are the reactions on such a mail like “100% On the nail ! Well said Luke…” or ” I am stupid enougth to imagine that the leader of the KDE developpment team could receive two salaries: with one coming from MS. I see KDE as something self destroying!”
Nobody called the people to order. Spreading pure hatred against KDE technologies and their developers seems to be perfectly acceptable inside the Trinity project.

Trinity – where will it go?

Given what I had seen over the last months by following the Trinity mailing list and partly the development it is quite clear that Trinity is a project for haters of KDE 4 technology. This is the only focus of the project and this is the reason for the ongoing duplication of work as they are unable to just even look whether KDE has already solved the issue.

Overall it results in pretty severe and dangerous design decisions. The hatred results in things like:

At one time there was a desire to port to Qt4, however months of solid work showed that Qt4 cannot provide the features needed to create a fast, efficient desktop geared towards mouse/keyboard interaction and high on-screen information content.

Well, I’m personally not surprised that you get this result, if you add a wrapper around Qt so that you can use Qt 3 and Qt 4 alongside. I’m also not surprised that this is the result if you have a mindset as illustrated above. If you want Qt 4 to be “worse” than Qt 3 in your project, you are able to achieve that. Don’t trust the benchmark you did not manipulate yourself 😉

So Trinity will keep stuck on Qt 3, which reached EOL on July, 1st 2007. Trinity thinks they can continue to maintain this orphaned code base – alongside the millions of line of code from KDE.

Can this work out? I doubt it. No developer knows the code and there is nobody to ask (and they don’t ask anyway it as I noticed myself). Given my personal experience of offering help I understand each KDE developer who does not want to have anything to do with the Trinity project and who would refuse to help them.

Looking over the mailing list there seems to be only a hand full of active developers, looking at the git repository it seems to be a one-man show. One developer to continue a development previously carried out by hundreds? At the same time facing the legacy issues like the deprecation of HAL, having to take care of packaging for all distributions. Finding rare issues like kernel is now 3.x and no longer 2.6.x? I rather doubt that this can succeed.

I have read quite often that “Qt 3 is now maintained by Trinity”. This is a pure lie. The development team is magnitudes too small to maintain this code base. Anybody running Trinity runs the risk of being exposed to newly discovered security vulnerabilities. It is quite clear that security issues discovered and fixed in enterprise distributions (e.g. RHEL, SLED) would stay open in the Trinity project (c.f. missing commits from enterprise branches) probably without even issuing a CVE.

Is there hope?

So what for those users who want a modern, classic Qt based desktop? Trinity will never be the desktop solution for it. The good news is that there is a sane project providing a classic Qt based desktop: Razor-Qt. It is built up on Qt 4 and has a clear project aim. Instead of just forking everything and the kitchen-sink, razor concentrates on providing a desktop shell. And the code is clean and well written, following modern approaches.

So my recommendation for all Trinity users is to either try again KDE Plasma 4.8 or to give razor a try. Trinity is no project anybody could seriously recommend and a stock KDE 3.5 is most likely a better solution than Trinity.

Posted on

About Compositors and Game Rendering Performance

Today Phoronix published (again) test results comparing the Game Rendering Performance on various desktop environments. As it “seems” like the performance of Game Rendering under KWin got worse in comparison to last year I want to point out a few things.

First of all: keep in mind that this is a test of Game Rendering Performance and doesn’t tell anything about the performance of tasks that matter. The development focus of KWin is clearly not on being great for games. We want to be (and are) the best composited window manager for desktop systems. That is what matters that is what we fine tune the system for.

Another important fact to know is that last years test was seriously flawed and I think this years test is flawed in a similar way. Last year KWin used by default unredirection of fullscreen windows while no other composited window manager in the test did that. With 4.7 we adjusted the default and turned unredirection off. But at the same time Mutter received to my knowledge unredirection of fullscreen windows. In case it is enabled in Mutter we have the explanation for last years bad results and this years good results.

If I would perform such a test, I would not benchmark KWin once but once for OpenGL 2.x backend, once for OpenGL ES 2.0 backend, once for OpenGL 1.x backend, once for XRender backend, the same set with unredirection of fullscreen windows turned on and once without compositing at all. We see there are so many things that would influence the game rendering performance that just one run of the benchmark is not enough.

But still we would recommend to turn compositing off when playing games. At least that is what I would do. A window manager is mostly just in the way of games and that is one of the reasons why gaming on desktop is by far not as good as playing on a gaming console. So if you want to game with KWin use the feature to specify a window specific rule to block compositing as long as the game is running. This will yield the best game rendering performance.

Posted on

KWin Effects written in JavaScript

Today I cannot make such a nice announcement as Aaron yesterday, but I can at least try announce something I personally consider as awesome.

This weekend I tried to make it possible to write KWin effects in JavaScript. After about two hours of work the effect loader was adjusted to load a Qt script instead of the library written in C++. This is a quite important step for the future of effects in KWin. It finally makes it possible to share effects via Get Hot New Stuff, so that our users can download new effects directly from the control module.

For packaging effects we use the well established Plasma Package structure, so that our script developers only need to know this one common way. The API itself will share as much as possible with the KWin scripting API – of course with adjustments for effects. For animating the API is based on the AnimationEffect introduced in 4.8.

From a performance point of view using JavaScript does not change anything. Our effect system has two phases: one to react on changes in the window manager (e.g. a window got activated) and one to perform the rendering. The scripting API only interacts with the window manager, so all the rendering is still good old C++ code – a similar approach to QML.

Now I guess you want to know what you can do with it. So here I present for example a Fade like effect written in JavaScript (for comparison: C++ version is > 200 SLOC):

var duration = 250;
effects.windowAdded.connect(function(w) {
    effect.animate(w, Effect.Opacity, duration, 1.0);
});
effects.windowClosed.connect(function(w) {
    effect.animate(w, Effect.Opacity, duration, 0.0, 1.0);
});

For us KWin core developers the scripted effects will be an important step as well. For quite some time we have been unhappy with the fact that there are too many effects which become difficult to maintain – especially if we have to adjust the API. With effects written in JavaScript this becomes much simpler. As we do not have to keep the ABI (API compatibility is enough) stable we can move effects written in JavaScript out of the source tree and make them available for download.

At the moment the JavaScript API is just at the beginning. But I expect it to evolve over the course of the current release cycle. For me the scripts are rather important as it also provides us an easy way to have device specific adjustments.

As I wrote currently the scripts do not operate during the rendering. Because of that we don’t have bindings for WebGL. This would at the moment not make any sense. Nevertheless it might be that we allow to upload custom shaders, but I won’t pursue such a task in the 4.9 cycle.

Posted on

Create Temporary Desktops For Applications

There are applications which are more or less a mess for a window manager. For example The GIMP opens quite a lot of windows and you want to have all of those windows visible. In general you don’t want to have any other window on the same desktop

The solution to that is to move GIMP on it’s own desktop. But how? We can use static window rules to get this working, but what if there are already windows on that desktop? The perfect solution to that would be to have a desktop which gets created when you open GIMP and gets removed again when GIMP closes.

This was so far not yet possible without manual interaction. But with todays additions to KWin scripting this became possible. Here I present a KWin script which does exactly that:

workspace.clientAdded.connect(function(client) {
  if (client.resourceClass == "gimp-2.6" && client.windowRole == "gimp-image-window") {
    // create a new workspace for the Gimp image window (kind of the main window)
    // switch to the new desktop and send the gimp window to it
    workspace.desktops = workspace.desktops+1;
    workspace.currentDesktop = workspace.desktops;
    client.desktop = workspace.currentDesktop;
  } else if (client.resourceClass == "gimp-2.6") {
    // send all other gimp windows to the current desktop
    client.desktop = workspace.currentDesktop;
  }
});

workspace.clientRemoved.connect(function(client) {
  if (client.resourceClass == "gimp-2.6" && client.windowRole == "gimp-image-window") {
    // when closing the gimp window let's remove the last desktop
    workspace.desktops = workspace.desktops-1;
  }
});

I should really start to publish the quite useful example scripts I write to test the scripting functionality on places like kde-apps 🙂 The API for 4.9 is documented on Techbase

Posted on

The Importance of Mentoring

Currently the KWin team is rewriting the work of two past Google Summer of Code projects. This is of course the worst thing which can happen about the projects. In retrospection we clearly have to say that the projects actually were failures – at least for the developer community. But both students succeeded their project, so we cannot say it’s the fault of the students. On the other hand the projects had different mentors, so blaming the mentors is too easy as well.

In this blog post I want to reflect why we consider the projects after more than one (respectively two) years as failures. What did go wrong and what can be improved in future projects? I hope this can be a help for more projects than just KWin.

I will base all examples on scripting – the project I am currently rewriting. Just to give an example of the scope: when scripting got imported into trunk it consisted of 3200 SLOC and now after the rewrite is almost finished it is down to about 500 SLOC which are mostly written by me. At the same time the provided functionality increased.

Don’t expect Students to Understand Complex Code

The scripting project should make it possible to have scripts run when “something happens”. E.g. if a window gets maximized the scripts should be notified. In the Qt way the best way to achieve that is by emitting a signal. Now this is what our student did. But in all cases I found so far the signals were emitted in the wrong place. So what is wrong?

KWin core works in a way that a user action triggers a method. E.g. entering the fullScreen mode will end up in Client::setFullScreen. But this method does not just perform setting the window to fullScreen, it also evaluates first whether it is feasible to set the window to fullscreen. For example the user might have established a window specific rule to disallow this window to go fullscreen. In that case the method will not change the state of the window.

The common pattern our student introduced was to emit the signal before the method had evaluated whether the window will change the state. So the scripts are notified with potentially wrong state change information.

Of course we cannot expect that the student for whom the code is completely new will understand these concepts. If you don’t know the internals of an application the behavior is in fact unexpected especially if it is only partially documented or commented.

Given this experience it is important to give a student enough time to get familiar with the rather complex code base. In this time it is important to provide the required help. In the example above it would have been a good advice to emit the signals whenever the effects are invoked – which happens at the same place (nowadays the notification of scripting and effects are merged) through direct method invocation.

Work in master

The Scripting GSoC got implemented in an SVN branch. For me as a team member and not being the mentor it was difficult to follow the development. In the end the branch got merged into SVN trunk without a review done by the team.

Some of the issues are resolved nowadays thanks to the git migration. So even if a student works in an own branch the team mates would get the commit mails and would be able to do a post-commit review on each commit. But still working in a branch for a long time brings disadvantages. Most likely the student is disconnected from the work. The team mates might work on the same code area, making merging more difficult – especially for a young developer who also has to learn to work with a complex VCS such as git.

So I think that it is most important to have the work been done in master (or any other development branch) directly. This might be tricky as KDE SC’s release schedule does not align well with GSoC, but as soon as the release branch is created there is no reason to not work on master.

Even while master is frozen the student should follow the common pattern and propose each change as a Review Request. This gives early feedback to the student and moves the burden of mentoring to the shoulders of the complete team. The team mates know what the student is working on and can provide early help and spot potential problems even if the mentor does not spot them. Remember: it’s not your student, it’s the team’s student.

Interfere before the student runs in the wrong direction

One of the tasks of a mentor should be to provide guidance to the student and ensure that the project goes in the right direction. I remember that my mentor did exactly that at one point were I started to do fancy stuff.

In case of the scripting project the student started to implement a kind of JavaScript extension for “Lazy Logic”. This was clearly not in the scope of the project, it might have been fun to implement for the student, but it’s nothing which is needed in a window manager. That’s just the wrong place to design new language features for JavaScript.

Given that the code was undocumented and I did not find any documentation explaining how this language feature works or why I would need it and last but not least I did not understand the code, it was one of the first code parts I dropped. This would not have been needed. The student should have concentrated on the task he is proposed to do.

Remember that the world is round

Yes, there are time zones. Yes most mentors have a day job and are restricted in the time they are available. It is no help to the project if the student works while the mentor sleeps and the student has to wait a day when he needs to ask questions to continue the project.

I remember that we had one project with the student living in Mexico and the mentor living in Australia. Of course this is a rather sub optimal combination. Don’t expect that the student will adjust his sleep rhythm. Even as a GSoC student he has the right for a normal social life.

Personally I decided not to mentor a student who doesn’t live in a European timezone. I just acknowledge with that, that I am constrained in time and that also all team members live in Europe, so we just cannot mentor students living on the other side of the world.

Communicate!

Communication is in my opinion one of the central aspects for a successful projects. During the project I mentored last year I tried to discuss the state of the project each day. And with communication I do not only mean e-mail or IRC, but also phone and personal meetings. If you live close to each other it might be a good idea to meet at least once, if the student lives in Europe Akademy is a must!

But communication is not only important with the mentor. Also with the complete team. The student should subscribe to the mailing list, read and answer review requests, be present in the IRC channel. His project benefits from it and the chances are better that the student stays after noticing how great the KDE community works.

Require Documentation

No code should be merged without documentation and without unit tests (if your project uses them). There is no excuse for a young developer to not write documentation. If the student works on a new area of code it is extremely important to have everything documented in a way that any of your team members can continue working with the code.

In case of scripting the code was lacking any documentation not even a high level description of the design was provided. This made it impossible to continue to work with the project. Trying to understand undocumented code can be more difficult than rewriting from scratch.

During a GSoC project you have the chance to enforce documentation. Make it clear that the student will not pass the final evaluation if the code is not documented. Documentation is not a nice candy, but at least as important as the code itself. Undocumented code is just unacceptable in the year 2012.

Be Prepared for the Worst

The worst for the developer team is that the student stops working with the last day of GSoC. This is bad but happens. The team has to be able to take over the project. A code dump is no solution and in doubt better not merge in the project than introduce bugs and instability. Yes that means that a GSoC project was wasted but it prevents a degeneration of the code base and does not bind your teammates to fix up the code.

In case of scripting we got a code dump which was completely undocumented and basically we have never seen anything of the student again. For me it would have been easier to just write the bindings from scratch than to fix up the project. Between the end of the project and my rewrite I had to fight several times with strange things done in scripting. So overall the project costs for the core team were higher than the benefits.

Adjust the proposed projects to the fact that the student will not be around after the project. $SUPERAWESOMEFEATURE is just bit crap if it cannot be maintained by your team. Use projects were you are sure that it will benefit the team even if the student will never touch the code again.

Adjust Your Own Expectations

Many mentors try to get just “cheap” work done and have the dream to get a new team member which might some day replace their position in the team. This might happen, but is rather unlikely. If that is your aim, you might head in the wrong direction. Now I can say lots about it, but there are people who can do that better, so I recommend to read the slides by Leslie Hawthorn from this years linux.conf.au.

The KWin team has learned from the experience with our failed projects. During last years project I was holding the hand of my student. For me it was important to get good code written and not much code or have him working on new areas. Also this year I will not mentor a project which would introduce a new area in KWin. E.g. Wayland support is out of bounds for a GSoC.

Posted on

Aurorae 3: Window Decorations with QtQuick

Once upon a time there was a window decoration which was KDE’s default decoration. But years ago it fell into a deep sleep. The world changed while the decoration slept. Compositing was added, decorations received shadows, Qt introduced the graphics system raster and many many more changes.

Now after years the decoration temporarily woke up, but it is no longer a beauty, but ugly and old. The changing world made the decoration break. The decoration’s bits started to rot and this is visible. The truth is that the decoration will stay in the broken state as there is nobody who would want to fix it or anybody knowing the code.

What I just highlighted here is true for basically all old decorations. Of the decorations we ship only Oxygen and my theme engine Aurorae are maintained. This is a situation which can no longer continue. We have to face the truth and remove all old decorations.

But of course we don’t want to remove decorations without adequate replacement and this leads us to the story of Aurorae.

Aurorae was written to experiment with new features introduced in KWin 4.3. It was based on our common decoration API and by that is rather limited. So for 4.5 I decided to port it to the generic decoration API and reimplement with GraphicsScene instead of QWidgets. Aurorae allowed to download decorations through Get Hot New Stuff.

But given that it is a theme engine the possibilities are still very limited. Only what the theme engine supports can be rendered. Porting our old decorations to the theme engine might not be possible and not to be recommended.

But still we would like to have those decorations on a modern basis without the maintenance costs. So I started to port Aurorae to QML. This does not only give us a more powerful theme engine but also introduces QML bindings for window decorations, allowing everybody to write decorations with QtQuick.

So we can write themes without the limitations of a theme engine 🙂 This does not only remove 3000 lines of C++ code and replaces it by around 1000 lines of QML code, but also gives us an interactive decoration control module.

Interactive decoration control module

For Aurorae based themes all the buttons are interactive giving our users the possibility to really try the decoration before using it. But that’s not where it will end. I want to have new themes not based on Aurorae but using QML directly. For that I want to use the Plasma Package structure and would love to see integration in Plasmate. Another idea is to support deKorator themes inside QML.

But as always this does not come without disadvantages. Not all features which were possible with Aurorae will be available in Aurorae 3. Some features will also be dropped because hardly any theme makes use of the features, for example special backgrounds for non-composited setups. Aurorae 3 will hardly work without compositing, so it might be that we will make it a hard requirement somehow.

I hope to see many innovative QML based window decorations in 4.9.

Posted on

What’s new in KWin Scripting?

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:
Plasma Desktop Console executing a KWin script

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.

Posted on

Was passierte im Fenstermanager für KDE Plasma Workspaces 4.8?

Es ist schon ziemlich lange her, dass ich hier mal auf Deutsch gebloggt habe. Nun nehme ich unser bevorstehende Release der KDE Plasma Workspaces 4.8 als Anlass um mal darüber zu berichten, was sich so im Bereich des Fenstermanagers und Compositors seit 4.7, welches in Kubuntu 11.10 zum Einsatz kommt, so getan hat.

Unser nächstes Release wird Bestandteil der LTS Version, d.h. sehr viele Kubuntu und hoffentlich auch Ubuntu Nutzer werden lange daran Freude haben.

In 4.8 sehen wir im Fenstermanager nicht besonders viele neue Funktionen. Wir haben hauptsächlich “unter der Haube” gearbeitet. An mehreren Stellen haben wir die Performance verbessert. Das Vergrößern/Verkleinern von Fenstern läuft nun dank einer verbesserten Synchronisierung mit dem Zeichnen der Fenster flüssiger. Wer es ganz flüssig haben will, sollte weiterhin den Effekt dafür verwenden.

Unser Verwischen (Blur) Effekt hat besonders viel Liebe erhalten. Alle Zwischenergebnisse werden nun im Speicher vorgehalten und nicht in jedem Frame neu berechnet. Das hat enorme Auswirkungen auf die Performance. Dank dieser Verbesserung (und einigen anderen kleinen Verbesserungen im Compositor dafür) konnte ich problemlos auf einer etwas älteren Ati X300 einen Fensterstil einsetzen, bei dem alle Fenster mit verwischtem Hintergrund gezeichnet werden. Auch können wir nun den Hintergrund von herausfahrenden Popups selbst während der Animation verwischen. Bisher hatten wir darauf verzichtet um die Performance zu schonen.

Weitere Performanceverbesserungen wurden unserem Effektsystem spendiert. Die Effekte können nun sagen ob sie gerade aktiv oder inaktiv sind. Dadurch werden sie beim Rendern eines Frames nicht berücksichtigt. Dies führt zu einer besseren Skalierung: die Anzahl geladener Effekte und offener Fenster hat keine Auswirkung mehr auf die Performance, denn in der Regel sind nur ein oder zwei Effekte gleichzeitig aktiv.

Eine sehr interessante Entwicklung ist der Einsatz von QtQuick. Diese Technologie haben wir im Fensterwechsler (Alt+Tab) eingebaut und können dadurch sehr einfach verschiedenste Layouts unterstützen. Hier ermöglichen wir unseren Nutzer eigene Layouts zu erstellen und zu verwenden. In der nächsten Version wollen wir das weiter ausbauen um auch Get Hot New Stuff zu integrieren um weitere Layouts aus dem Internet herunterladen zu können.

Generell sehen wir in QtQuick sehr viel Potential und wollen dies in 4.9 verstärkt einsetzen um den Nutzern somit ein Werkzeug in die Hand zu geben um einfacher seinen Fenstermanager zu gestalten und die eigenen Ideen in die Entwicklung einzubringen ohne C++ beherrschen zu müssen oder KDE Plasma überhaupt bauen zu müssen.

Rückblickend bin ich mit der Entwicklung in 2011 sehr zufrieden und freue mich auf das nächste Jahr um die Früchte zu ernten von der Arbeit, die wir dieses Jahr begonnen haben. Ich kann nur jedem Nutzer empfehlen den KDE Plasma Fenstermanager in Version 4.8 auszuprobieren und mal neben Unity oder GNOME Shell zu versuchen. Dank der Flexibilität unserer Desktop Shell Plasma können Nutzer auch ohne großen Aufwand ihre bevorzugte Desktop Shell – sei es Unity oder GNOME Shell – nachbauen.

Aber damit 4.8 ein richtig tolles Release wird, sind wir auf eure Mithilfe angewiesen. Aktuell ist der Release Candidate 1 veröffentlicht und wir brauchen noch mehr Tester. Von Kubuntu gibt es PPAs um die aktuelle Entwicklerversion zu bekommen. Wenn ihr ganz sicher gehen wollt, könnt ihr auch Neon verwenden, das die Pakete getrennt installiert. Testet, findet die Fehler, meldet sie, damit wir Entwickler sie noch vor dem Release beheben können.

Und wenn ihr nicht wisst, was ihr mit dem ganzen Geld machen sollt, dass ihr zu Weihnachten geschenkt bekommen habt, so empfehle ich euch eine unterstützende Mitgliedschaft im KDE e.V. (Ich bin auch zahlendes Mitglied.) Dies ist ganz wichtig, denn mit euren Spenden werden die Entwicklersprints finanziert, welche wir Entwickler benötigen um die zukünftige Entwicklung zu koordinieren. Vielen Dank!