I would post a screenshot of what this is going to be about, but the screenshot would look remarkably similar to other KDE3 screenshots I could post. Unless I switched the decoration to Oxygen/Ozone, but then yours truly is still quite happy with the KDE2 decoration (and then, also not quite happy with all those people who think that anything that's older than a year, especially if it's not shiny, must be oh-so-bad), so let's just skip that. You can try yourself after all.

SVN trunk (KDE-to-be-4.1) now has a selection of several window managers for KDE to use in the 'Session Manager' module in the control center (AKA systemsettings), which serves as a more friendly alternative to $KDEWM (although that one remains supported). The benefits are several:

• People who don't know about $KDEWM should be still able to handle this and change their window manager as they like.
• Compiz users will hopefully stop using the ugly Autostart hack and then even occassionally complain about how it breaks things in subtle ways. Updating to a Compiz version that will include my few fixes for its rather broken session management support may be useful, although I think I've already worked them around in ksmserver too. The default command to launch Compiz is 'compiz cpp', but you can create a custom one too (beats me why launching Compiz needs to be such a voodoo magic when for pretty much any other window manager Foo the right way to launch it is just 'foo'). Together with KDE4 mapping Compiz' viewports transparently to virtual desktops there should be hopefully no problem with running Compiz in KDE for those who want that.
• People can add more window managers to the list to $KDEDIR/share/apps/ksmserver/windowmanagers (kdebase/workspace/ksmserver/windowmanagers in SVN).
• I backported the patch to KDE3 and the latest packages in the openSUSE KDE:/KDE3 repository now have it (well, slightly older ones have it too, but broken, the correct ones have a changelog entry about fixing a patch for bnc#332079 from May 19th). And openSUSE11.0 is going to ship it (users of other distros will probably have to dig it out of the package or apply some other kind of magic).

The last item of course means that those not brave enough to use KDE4 can still use at least KWin from KDE4 and get compositing, without regressions in the feature set or window management area (hmm, is that a very cheap jab at Compiz?). Unlike with other KDE4 components, we were too busy with compositing and didn't have time to break KWin , which means KDE4's KWin in non-composited mode should be as good as the one from KDE3 and you won't be missing any features you're used to. The only problem I'm aware of is that the dialog for assigning a specific shortcut to a window (i.e. Alt+F3/Advanced/Window Shortcut) does not work as a result of the somewhat problematic shortcuts rewrite for KDE4, and, of course, some small bugs might have slipped in somewhere. Whether it works for you even with compositing enabled, well, that's up to you to try. And, pretty please, read the section on setting up compositing. When KWin refuses to activate compositing, it's for a reason, so if it doesn't do anything for you, it's a problem between the chair and ... erm, configuration, I'd bet my hair color on that (oh wait, that's already taken).

KWin from KDE4 of course will not work as well in KDE3 as it does in KDE4, but that's mostly details like Kicker's taskbar not having support for taskbar thumbnails, so that effect does not work there. Also, the settings are separate, so you may need to set KWin up again (I suggest copying kwinrc and kwinrulesrc from ~/.kde/share/config to ~/.kde4/share/config before switching). But generally it seems to work quite fine ... ok, I give up, maybe one picture after all.

In other KWin-related news, there are now two new things that should help when something goes wrong with compositing, more or less obsoleting the more manual fixes from the troubleshooting section. First one should be a special KDE4 failsafe session in KDM, which should launch KWin with compositing forced off. Second is a shortcut, Shift+Alt+F12 by default, that temporarily suspends compositing, until the shortcut is pressed again. That should help with finding the checkbox to turn off compositing again in case it goes awry , but it can be also quite convenient when e.g. running a game that needs all the power the graphics card has.

Unfortunately neither of these has made it into openSUSE11.0 due to freezes , however in case of trouble blindly pressing Alt+F2 and typing 'kwin --replace' should start KDE3's KWin, which should do in most cases.

In fact, there is probably a third thing helping with compositing problems too. When I was in Nürnberg some time back to see the rest of the team, I noticed Dirk running KWin in XRender mode. What a surprise, does somebody actually use that ? So I checked that mode again and fixed/implemented the most visible problems. Which means, if OpenGL compositing does not work for you, you can still go to KWin compositing settings and there in the Advanced settings try switching the mode to XRender. Some of the more complex features don't work with XRender (and few are not implemented yet, there should be XRender shadows from Thomas Lübking soon though), but in general XRender may work better for you.

As every year, one can see all kinds of articles related to today's date everywhere, ranging from quite amusing ones (it's a pity I knew what day it was when visiting dot.kde.org) to really old boring ones without anything interesting in them. I guess many people are running out of ideas or something. Rather that doings things like that, I think such people should simply stay serious. Like myself, I'm a pretty boring person usually, so I won't join the crowd, but I'll rather try to fight back by trying to be serious.

People who have tried KWin's compositing have different views on how well it performs. I have seen comments starting from "it's so unusably slow, and Compiz runs fine here" to "it runs so great, unlike Compiz". I guess it really depends on one's luck and the gfx card, X version and drivers in use. Here KWin runs comparably to Compiz, and that's with several different setups (and gfx cards, and drivers). Quite hard to do something for people where it's bad for some reason, really. My crystal ball refuses to work whenever I try to use it on compositing problems, and here compositing works for me (TM).

Actually, that's only with either the development version of KWin or the to-be-4.0.3 version. Some days back I found and fixed some inefficiencies in KWin that were way too often causing pixmap-to-texture conversions, slowing it down, or other problems (see the 4.0.3 changelog when it's out). These fixes also allowed me to again enable KWIN_NVIDIA_HACK trick (i.e. __GL_YIELD=NOTHING, see Nvidia's README), making KWin actually seem to perform even better there.

Update: Saying that one is not going to fool anybody does not necessarily mean this saying is just not part of the fooling. It was for a reason why the first paragraph and the very last sentence were somewhat ambiguous. It seemed funny at that point for some reason. But I guess I took it a bit too far with pretending all of this is serious, most people probably don't have the knowledge to know that, since compositing is an additional pass, it cannot make things faster in general. Although, and that should be the lesson, things rarely in practice magically become five times faster. Glxgears is not going to actually get more work done just because you postprocess it. So yes, sorry, the part below and the video are a fake.

However, the parts above are not, they are true. I really have recently done some optimizations in KWin and it runs here comparably to Compiz (on some setups slightly faster, one some somewhat slower, but it's not a significant difference). And, with the Nvidia trick, the perceived performance for some users in some cases actually may seem to be five times better. And, this time unfortunately, the parts about it mostly working for me and it being difficult to do something about problems other have that I don't see are true as well.

End of update. The video that follows is a fake.

And, speaking of tricks, as a result of seeing and fixing those problem, in my local version I've tried some more performance improvements based on that. By applying even more optimizations to KWin's handling of pixmaps and OpenGL textures, KWin now can avoid even more unnecessary redraws or pixmap-to-texture conversions, leading to a rather noticeable difference. In fact, since it's an accelerated desktop, glxgears running with KWin's compositing now even runs faster than without compositing (I know glxgears is not that great a benchmark, but it's good enough for some uses). You can see it for yourself here, or if you've found out that Flash sucks, then you can download the video here (you'll probably need to set the video to fullscreen to see the FPS numbers in Konsole). As you can see, the gfx card is not very fast, and the recording of the whole screen for the video makes it appear even worse (throughout the whole video, unfortunately, that's why some parts are quite choppy).

That's all, the usual old boring stuff .

I guess many people see KWin only as 'the window manager from KDE', but there are actually things that can make KWin beat many other WMs - features (some of them first introduced in KWin, such as the focus stealing prevention), compositing, tested codebase, handling of various broken apps, configurability, window-specific settings. I introduced window-specific settings to help with many special cases (broken Java apps, focus stealing prevention problems in corner cases [BTW, Metacity until recently didn't have any option to turn its focus stealing prevention off at all, and even now it's only all-or-nothing - I wonder if people learn to live with such problems, or how come], or simply I-have-this-very-special-case-when-I-want-this-window-do-this). But as you know, it's never enough, and there are some requests to make the somewhat large window-specific settings dialog even larger. I really have no idea how I should create a decent GUI for cases like 'when a window is maximized do ...'. Nor I am going to try anyway, for such really special cases. Contributions to KWin core are quite rare (except for people working on compositing, for which I'm really grateful) and I'm only a human.

However, the solution for this shouldn't be that difficult. Special cases can never be really handled by generic code, so the obvious way seems to be scripting. And after a while of starting at QtScript docs (I have only little clue about scripting) I created a quick KWin patch as a proof of concept. With it, a Javascript snippet makes all new XTerm windows appear on desktop 2. Of course, for this to make it into SVN it'd still need some work, most of which looks at the level of Junior Jobs or slightly higher: Make it preferably use Kross instead of QtScript, support for loading the scripts instead of having it hardcoded in the sources , making sure it won't slow down KWin to a crawl, support for scripts getting access to more functionality and error checking (which is the reason why the patch creates a wrapper class for window instead of letting the scripts access KWin internals directly, right now e.g. KWin crashes if the script returns wrong desktop number, and I also really don't want to handle bugreports of a window manager that lets people mess with its internals).

So, people who don't want to do anything with KWin's code for unknown reasons but want new things from it, now you have a chance (of course, it involves temporarily doing that, but nothing is perfect, right ?). I can handle writing KWin code quite fine, so I have little motivation for this getting finished, sorry.

As of now [*], I hereby declare that KDE4 kind of supports viewports[^] (that is, the implementation of virtual desktops that Compiz and probably practically nobody else uses). Which means it possibly still sucks a bit here and there [x], but it's at least as good as in GNOME. In fact, after little checking[!], it appears that it is a bit better (try e.g. dragging a window in GNOME pager with Compiz running). Strange, I remember loads of people complaining about KDE, but not a single case about GNOME - maybe I just haven't noticed, or GNOME has less features that can break in the first place, or maybe that's what we here call 'one-eyed the king in the land of the blind'[-]. Anyway. The good news for KDE developers is that they don't have to care - viewports are mapped to virtual desktops by libraries[#] and only the pager seems to need few small tweaks. That in fact seems a much better solution than the KDE3 way of actually really trying to support viewports (I think I feel shame remembering I supported this and thought it was a good idea - one never stops learning). Which means a backport to KDE3 would be problematic, maybe I'll try for openSUSE11.0, but I'm not very confident that's a good idea. We'll see.

Time for the small print:
[^] Viewports suck.
[*] That actually means next Monday, when I enable one small check in pager that requires new kdelibs functionality added today.
[#] Well, at least the theory is that viewports can be transparently mapped to virtual desktops, reality may possibly decide to disagree on some aspects.
[x] Viewports will never be perfect [.].
[.] And, frankly, I'm not even that interested in making the support as good as possible[_]. Despite what some people might probably think, I'm still human and reasonably sane[y]. Years of working with Xlib and other things probably have increased my pain threshold, but I can still only take so much. Taking care of some minor details would be a major pain.
[y] Although I admit protecting others from these insanities may have some unpleasant effects. Caution suggested when approaching.
[_] That said, the support should be good enough, and, as said, probably better than GNOME's at the time being.
[!] I checked with GNOME shipped with openSUSE10.3, so maybe that's improved since then[?].
[?] I noticed that the SUSE packages for the related functionality in GNOME actually have patches with some viewports code added[/]. I wonder how it works elsewhere.
[/] It seems GNOME basically has code path for virtual desktops and then the same again for viewports. I guess Havoc wouldn't like that[@].
[@] There are many things about Metacity design I don't agree with, but I think I strongly agree that having both virtual desktops and viewports is crackrock[$].
[$] Well, here I wanted to note that this is a quote from Metacity's README, but while apparently many things are crackrock according to it, this subject seems only doesn't make sense, so that's me saying it, ok[+]?
[+] Well, I guess it saved some work in Compiz, but I have to wonder if the idea of going with viewports was really worth it.
[-] No warranty included at all.

Today, in one user forum, I noticed somebody saying that they use different virtual desktops for different things and therefore they'd want different panel for each desktop. Our bug #79531, more or less. One interesting note is that the user uses GNOME, but would be willing to switch to whatever provides this feature.

Kicker does not support this, nor does GNOME panel it seems, and I doubt any panel actually can do this. However, since one can create multiple panels with Kicker, it should be sufficient to put each of them on a different virtual desktop. Kicker can't do this, but should be this allmighty window manager thingy. Alt+F3/Configure Window Behavior->Window-specific settings, click New, click Detect, select a Kicker panel, confirm and then apply any desired changes - in this case it's going to the Geometry tab, enabling Desktop, setting it to Force and choosing the right virtual desktop.

That should do it. Except that, in this case, it doesn't, as KWin cannot uniquely identify the panels. They all claim the application is Kicker, but the role ("xprop | grep ROLE") is always ExtensionContainer - object name (QWidget::setWindowRole() for Qt4) for all of them is the same and I had to fix it in SVN. Now it works. Eventually, when KDE4 development becomes a bit less exciting again , I plan to put code somewhere in kdelibs that would check for this and annoy people.

And there are other tricks one could do with KWin's window-specific settings, so it's a pity that the help for it is very short and unsufficient and I haven't found time yet to write good docs for it (well, and I'm lame at that, too). How about, if there was somebody who can't code, but would like to contribute to KDE anyway, created the docs for it ? Interesting topic for many people to read, and docs howto should have info on how to make that part of KDE. I'll answer any questions necessary. Any takers ?

PS: The widget style in the screenshot is the B3 style (variation of the so-called Highcolor). Since I'm already naively asking for things, could somebody port that to KDE4? I'm bad at styles too.

What was it ... ah, yes ... KDE4.0 has been just released ... just in case you haven't noticed yet in all the other blog posts all around.

No, in fact, the thing I really wanted, was: People, the proper capitalization is "KWin". Not "KWIN", not "Kwin". It is the KDE Window Manager, just like KCalc is the KDE Calculator, KPat is the KDE Patience Game or KMenuEdit is the KDE Menu Editor. Okay ?

And, the one more thing I wanted: In addition to the KDE4.0 Visual Guide, which includes KWin, it was planned to also create a KDE4.0 KWin video, which would present most of the effects shipped with KDE4.0 and would explain them (so that people would know how to use them well and also would not go commenting 'useless' about things like the Invert effect which perhaps may be useless for some but can be very useful for others). This unfortunately did not happen in time for 4.0, but hopefully somewhen later. You can now at least check http://www.digg.com/linux_unix/KDE_4_0_0_KWin_Composite_Showcase for a recent video made by somebody else, which I found completely accidentally while Gooling.

One of the things that distracted me from making the video were KDE4.0 KWin release notes, which I actually currently consider more important than the video. It includes introduction, setting KWin composite up, basic description of using some of the effects, troubleshooting and various other things that seemed important to mention.

It also includes a FAQ section that will probably grow. Right now it includes explanations about (apparently very popular) why not simply drop KWin in favour of Compiz, why not at least use Compiz plugins in KWin when we don't drop KWin completely and why it is actually worth bothering with KWin when Compiz is so much better anyway. I've got such a strange feeling the list will need to get bigger.

As one of my colleagues notes, this statement holds true on its own. However, for those like me too blind to see some things, there are two things about Flash you should know:

1. The latest Flash update fixes various critical security issues.
2. The latest Flash update does not work with anything that is not Gecko-based.

Do the maths yourself. Or just watch it happen as soon as your distribution's update hits your machine.

I'm not going to comment on the first one, but, as a person who has spent a good portion of the last two weeks trying to find a solution, I know some things about the second.

First of all, this is apparently perfectly fine with Adobe. According to their system requirements page, they care only about Firefox, Mozilla or SeaMonkey. Tough luck if you use something else (by the way, according to the latest Linux desktop survey, this something else is at least a quarter of Linux users). Imagine a critical security issue that will exist only when using Flash in Konqueror or Opera but not in Firefox (for whatever reason, like Adobe testing Flash only in Firefox) - care to guess what happens in such case? After all, you can give it a little test - just try to find out what happens if you complain to them that Flash doesn't work for you in Konqueror.

You know, I haven't been a huge fan of Moonlight, but there's definitely at least one thing to like about it - it's open source. Doesn't work? Have a look at the code.

Not so with Flash player. The reason why the latest Flash doesn't work originally appeared to be its new support of some Mozilla XEmbed-based extensions to the plugins API (funny thing about that link is, it says that it finally makes it work with Opera, while in fact it's exactly the opposite). After adding XEmbed support to Konqueror, it still didn't work. The page about the XEmbed extension has demo code hardcoding a hard dependency on Gtk2, so maybe adding Glib2 eventloop support will make it work? After all, the Flash system requirements page mentions this (well hidden in a footnote, if you look close enough), but not really, tough luck, even though the DiamondX testing plugin already works. Do you know what a ballistic approach to debugging is? You either hit, or you don't. Here next hit is that this Flash version doesn't handle properly repeated NPSetWindow() calls, which however happens to be the case with Konqueror. So finally, does it work? Well, kind of, if you don't mind it crashing everytime you leave a page. And it crashes in XtRemoveTimeOut() (incidentaly, a function that should not be called by a Gtk2-based plugin). That's been already taken care of as well - it's enough to give Flash the user agent string from Firefox, suddenly, no crash (I have no idea how Maksim managed to find this out - probably involved sacrificing chicken or something).

So, when can you expect the latest Flash to work with KDE? I have no idea. There are some preliminary patches I've made and committed to SVN, those may or may not work for you, depends on how lucky you'll get. Given that people report random crashes with those, I really meant to say lucky. Right now I'm trying to debug another issue where a proper fix that should remove a race condition actually prevents it from working. I also can't get keyboard focus right, even though debug output from DiamondX seems to look correct and I can't see any significant difference to Firefox. Maybe my fault ... maybe not, given what I know about how Flash handles keyboard input (you don't want to know).Opera people apparently have been more lucky with dealing with this, their latest beta should work better, but I could notice some problems there as well.

So, sorry. E.g. OpenSUSE will probably ship KDE updates for this tomorrow, but I suppose you'll be better off using the one true browser for the time being, if you need Flash. Next time I provide KWin videos only on youtube, somebody please yell at me. A lot. I'll deserve it.

PS: Yes, I know a Flash developer contancted kfm-devel somewhen in the past asking about XEmbed support. That still doesn't make debugging Flash any less painful, which is why the workarounds for it will take unknown time. It also doesn't change anything about Adobe not really giving a damn about Konqueror or Opera, if they could suddenly drop backwards compatibility (even though the code is probably still there, if it can still call XtRemoveTimeOut() and crash on it).

(I suppose using such number for this part makes the previous blog entry, part IV, written already quiiiiteee log ago, to have a wrong number, but who cares about that nowadays, it's just numbers, right? Anyway, it was so long ago that even I don't remember what it was about, which means I now have to think what to write about now. Hmm.)

I suppose I should maybe show some videos or screenshots again, but hey, we need testing for almost-KDE4.0, so if you want to see them, you need to use your own eyes for that. Besides, I don't remember what's new since then anyway, and I'm too lazy to check SVN. Ah, well, maybe one comes to mind:

It is not a broken image but an effect called ShowPaint, which with various colors shows parts of the desktop that need redrawing. One can for example see that the KPluginSelector widget in the dialog redraws just on mouse being moved, that taskbar items repaint at least for 10 seconds after an animation has already stopped or that the Shadow effect is a bit too generous with causing repaints around windows (well, you obviously quite can't, since it's just a static picture, but in reality those parts flicker). Those are hardly critical right now, although such things can reduce performance of the composited desktop, and I also suppose the tool can be useful even for other developers.

But most work recently has been going under the hood. Although there have been also new visual features like the Login and Logout effects, most work has gone into the usefulness and stability areas. The sooner being e.g. config dialogs or keyboard usage in PresentWindows and DesktopGrid effects, not shown in these old linked videos of course, but simply try hitting keys that make sense, like arrows or F<n> (BTW, there's one thing I'd like to get in other places in KDE/Qt - wrapping around works only without key autorepeat, that is, hitting Down once on the lowermost item will go to the topmost, but keeping Down pressed will stop at the lowermost - I really hate what holding Down pressed currently does e.g. in Konqueror's iconview).

However the testing and stabilizing work is now the most important one. It looks like we've made it for 4.0, with KWin compositing being usable and in quite good shape, although, indeed, it'll be still marked experimental and with few glitches (sorry if you'd like to use window shading with compositing in 4.0). The biggest question now seems to be whether to have it in 4.0 enabled by default, if possible. Even with Compiz having been around for like, what, almost two years, and XCompmgr even longer, support for compositing still has some rough edges (check, for example, kwin/COMPOSITE_HOWTO, and I've run personally into every single of the issues listed there - I really don't want to know what David Reveman's buglist sometimes looks like). I still haven't decided on that one - we certainly want testing, but people unlucky enough to end up staring at a screen full of white squares with shadows around them probably wouldn't appreciate it.

Well, and while I have the attention , few things:
- Bug reports go to bugs.kde.org. Including useful details like X version, driver and whether it works with Compiz (where applicable) would be nice.
- The API for the effects, just like rest of the compositing stuff, will be marked as experimental and unstable for 4.0. We even intend to document it in time for final 4.0 release .
- I've said this one enough times to make it really boring, but just in case somebody has missed it yet for an unknown reason, people interested in helping with the development are welcome on the kwin@kde.org mailing list.
- People complaining about problems caused by them not having read the above-linked COMPOSITE_HOWTO will be assaulted by a hired specially trained mercenary commando of lethal chipmunks and will be publically spanked. I have a large storage of nuts and I mean it.

I did a presentation on compositing managers at the local LinuxExpo last week. Using kwin_composite for demonstrations. And KWin actually did its job quite fine (although it had taken quite some effort to get it there, with KWin being almost ready for it for more than a week). What did somewhat worse was the human factor - having more than 20 shortcuts wasn't a very good idea and failing to show the final and best feature because the bloody modifier was supposed to be Ctrl was a bit embarrassing. Oh well. C'est la vie. The good thing is that there are more things to show.

First video, DimInactive and DialogParent, shows a feature asked for in bug #46226 - dimming out inactive windows in order to increase contract for vision impaired users. Fixing it without compositing support was next to impossible. The video shows also darkening of windows blocked by modal dialogs, I think I've already shown a static picture of this one before.

Second video, Zoom and Magnifier, may also look like accessibility features, but they'll definitely come handy also e.g. when visiting some pages where the designed was an idiot thinking that using 6pt "big" fonts is perfectly fine.

Third one, FallApart and Flame, are some eyecandy (not really useful in practice if you ask me, but maybe that's just me). And yes, the second one _is_ the window burning down, it's just that there's no actual flame drawn, since I'm so bad at graphics. Feel free to do something about it, should be very simple.

Fourth video shows live thumbnails during various actions and, as the last thing, a thumbnail of the window is added to an edge of the screen - should be useful for keeping an eye e.g. on a running compilation. Just in case somebody asks, the video is one of Novell videos, called Take Command.

Fifth video is just plain PresentWindows, the well-known effect showing all windows. The thing that should make it more interesting is the filtering of the windows (the underlining was done with a touchpad, bear with me, I hate touchpads).

The last one, the one with the Ctrl shortcut, is DesktopGrid. A slightly more improved version of the pager. Just like the cube this is a way to make a more intuitive representation of virtual desktops, maybe not as flashy but IMHO somewhat more useful.

And finally, since the kwin_composite branch, while still far from being done, is not really different from trunk when compositing is disabled, it will be merged soon back to trunk, defaulting to compositing turned off.

I finally find out recordMyDesktop and played a bit with it. Animations are a bit boring as PNG images after all. Too bad the recording seems to take up quite some resources and the videos look a bit jerky because of that (GeForce2 is not that slow ). I had to intentionally make some of the things slower and take longer and it still looks worse than in reality. Oh well. Ok, some new things in kwin_composite from Rivo Laks, Philip Falkner and yours truly:

- COMPOSITE_HOWTO, the starting point doc for kwin_composite.

- PresentWindowsEffect - a simple demo effect presenting all windows on the screen. Also shows the support for keeping contents of windows that are currently hidden, can be later used e.g. for thumbnails for taskbar entries.

- ZoomEffect - shows the screen with double size, in this case. Can be e.g. useful with all those webpages created by "designers" thinking 7pt fonts are a pleasure to read. This video is actually taken in XRender mode, not OpenGL (because I wanted to show it and because, er, it's currently broken with OpenGL, reason yet unknown). The screen follows the mouse cursor in order to make the mouse to work - X currently has no support for input transformations. The black color in the FPS graph after turning the transparency on shows that XRender performance is not exactly stunning (or is, depending on the interpretation).

- ScaleInEffect, FadeInEffect and FadeOutEffect - the fade out effect shows support for keeping contents of windows that have been already closed. The other two are there just for the fun of it.

That's enough for now, I'm getting really sleepy . And it really looks better for real. No XTerm's with debug output, smoother because no screen recording slows it down, the FPS graph is not so red all the time, oh and the (completely non-existent, of course) crashes accompanying the work in progress also feel more real.

Rumour has it that KWin was so happy because of these changes that it celebrated a bit too much and got seriously drunk (investigations are already underway and the video taken shows a suspect, currently only known as the 'International Dragon of Mystery').