If you look at for example kde-apps.org or kde-look.org, there are numbers of various KDE applications, utilities, styles, decorations and what not. Various contributors post there their work for others to try and use. This is the place where new software or other contributions often look for their first users.

However, if you look closer, you may notice one problem - most of them are only provided as the source tarball, with no, few or old binary packages. Sadly, here the old jokes about how difficult it is to install software on Linux are still valid - it is not difficult to find applications with comments along the lines of "I tried to compile it, it said <whatever error>, what do I need to do, help". The difference between providing or not providing a simple way to install your newest creation can be the difference between users using it or not.

This may not seem to be that simple to solve though. There are probably only very few people who have all the major KDE distributions installed, let alone actually know how to create packages for all of them and have the time to do that. There are other community members who sometimes provide binary packages, but those only do it for a selected range, and they have to update them as new versions are released. More lucky contributions get picked up and packaged by distributions, but that can be difficult for new ones, since simply they are new and not many users know about them. So it looks like the usual kde-apps/kde-look/whatever contributor needs to depend also on luck to actually even reach the potential users.

Well, for those who still don't know it, let me introduce you: KDE contributors, meet the openSUSE build service; openSUSE build service, this big bunch of people are KDE contributors.

The openSUSE build service is a tool that is used to build the openSUSE distribution, but it can be also used to build additional software for openSUSE (such as the additional KDE repositories that provide various KDE versions). And, what many people might not know, it can be also used to build software for other distributions.

In fact, I've been looking into the possibilities recently, and, in the process of it, I have packaged a bunch of random kde-apps/kde-look stuff in my home repository. And, right now, I have packages for various openSUSE versions and SLED 11, Fedora 10, Fedora 11, Mandriva 2009, Mandriva 2009.1 Spring, Kubuntu 8.10 and Kubuntu 9.04. There are some more distributions supported, for example Debian, but those do not yet have a stable release containing KDE4, so tough luck there.

And I tried to cover various possibilities of what gets posted on kde-apps/kde-look:

• I was probably the first one to package the KWin Aurorae SVG decoration engine by Martin Graesslin soon after he had announced it there, as soon as the necessary KDE4.3 beta2 release entered the KDE4:UNSTABLE repository. I also packaged the Nitrogen KWin decoration, just to have a decoration that builds on more distributions.
• I packaged a set of the Glassified KDM, Plasma and splashscreen themes. The themes were actually just tarballs containing the files (and that actually gave me a hard time when trying to package that for Ubuntu) that need to be uncompressed into the right place, but still, there is the convenience of just installing a package and be done with it.
• I miss the ability switch using keyboard shortcuts between taskbar entries like it was possible with Kicker. There was feature freeze, so instead of providing a patch for Plasma I went for a temporary solution and wrote a simple KDED module hacks that does it. And from the moment I uploaded it to kde-apps as TaskbarSwitch there were also binaries.
• I packaged KShutdown, Ksshaskpass and Kvkbd as examples of various applications. Together with Ksshaskpass I also created a local modification of the openSSH package and sent a request to its maintainer to include a change that enables openSSH to use Ksshaskpass. Kvkbd needed a patch fixing it to work with the XDM/KDM setup on openSUSE.

And the best part about it is that it was actually quite simple and easy. I just took a template for .rpm and .deb packaging, filled it in, tweaked a bit if needed and submitted to the buildservice. Then checked the results after a while, fixed problems and now it is all in home:llunak:kde, ready to be used. Anybody who can code a small KDE application shouldn't have a problem to do the same and then say that the package is in the repository home:<whoever> and that the installation instructions are at http://en.opensuse.org/KDE/Build_Service.

Of course, it was simple and easy for the Lubos Lunak who wanted to package those things, as that was the point. The other Lubos Lunak, the one trying to ensure it was that way, had it a bit harder. The openSUSE Wiki has a lot of information, but it was necessary to read it and try it out. Some work was needed for building from one .spec file for all RPM distributions (really just one .spec, the only package that needed conditionals was Ksshaskpass, and only because I knew the special handling needed to fit with openSUSE's openSSH). It is of course possible to build for each distribution using their .spec syntax, but I wanted the possibility of having just one syntax that would be mapped automatically as necessary using macros and package renames. Some work was (and still is) needed to help making .deb packaging as shared with .rpm packaging as possible (I think I can forget generating it automatically from the .spec, but for example Debian/Kubuntu build system accepts only .tar.gz tarballs, so there is a build service patch from me pending to make the possible conversion automatic).

That work is going to be only mine, though, the plan is still to make it easy for you. Well, ok, I wouldn't mind if at least somebody added better details to the distribution-specific pages linked from the main page, because I e.g. haven't managed to find out how to easily add a new custom repository on other distributions. So if you are waiting now for a howto, this will need to wait for a while, until it is prepared and cleaned up. You can however try to bribe me at Akademy into demoing it personally .

Since Kendy's blog has somehow disappeared from Planet KDE, let me copy&paste one entry (http://artax.karlin.mff.cuni.cz/~kendy/blog/archives/monthly/2009-06.html#2009-06-15T14_37_23.htm):

Thanks to the heroic efforts of Éric Bischoff, Bernhard Rosenkränzer, and Roman Shtylman, the OpenOffice.org KDE Integration has been ported to KDE4. It still has some rough edges (currently the detection does not work out of the box—you have to export OOO_FORCE_DESKTOP=kde4 to get it), but it is safe because it co-exists nicely with the existing KDE3 integration; so if you are not satisfied, you are able just swich back to KDE3 (export OOO_FORCE_DESKTOP=kde).

For KDE4, Roman is also changing the out-of-process implementation of the KDE file picker to an in-process implementation, so you'll probably notice some performance improvement of the KDE file dialog launch too

End of copy&paste. For people who'd be interested in helping with this, I've been told those should join #go-oo on Freenode.

I found out today that two of my colleagues in the office have the same problem with Firefox - when clicking on a link in a mail client, their open Firefox is brought to the current desktop from wherever it was before. Rather annoying I guess (especially for the normal mode of operation with Firefox, keep-it-running-all-the-time-on-its-virtual-desktop), and I bet they've lived with that for quite some time already.

And handling this can be so simple. One of them uses KDE, so it was just switching to Firefox, Alt+F3/Advanced/Special Window Settings, enabling Desktop there, setting it to Force and choosing the virtual desktop it's supposed to be pinned to. Problem solved (or rather worked around, of course). The other one uses GNOME and I have no idea how to help him - Metacity itself does not have any such "advanced" functionality and Devil's Pie probably can't force settings. Bad luck. Maybe one really really long bugreport in GNOME bugzilla has a trick somewhere (the "fixed" resolution is unlikely to be it though, since it breaks other things).

The lessons learned could be: 1) It can be useful to have ways to handle exceptions. 2) KWin can do quite a lot, just check out the window-specific settings, and it can do it because as a window manager it should have the ultimate say about what happens. 3) If you refuse to aknowledge that the window manager is a manager and try to outsmart it or roll your own in your application, it may hurt when you shoot the foot.

As some might have noticed among all the praise, some of the features may not come at low cost. One of the biggest memory hogs in KDE4 is (again) something that doesn't have much to do with KDE itself - the OpenGL library shipped with the nvidia driver. It is compiled without -fPIC to gain a couple percent performance increase (if at all, I personally doubt it makes a noticeable difference, but that's just guessing, given it's closed-source). And that means that every single application that links against it wastes about 11MiB RAM (on 32bit system), per process, regardless of whether and how much it actually uses it. And currently there are 5 such processes in just the plain KDE desktop, and count in the X server too. Do the math yourself. Or just have a look at the picture of Exmap showing it:

It's the 'effective mapped' column, see the howto for more details.

Speaking of Exmap, it sadly appears it is no longer maintained, which I find quite bad, because it's still the best tool I know for measuring memory usage. It still works though, after a little of patching, so I packaged it in the openSUSE buildservice (you want the xxx_Update repos, unless you've never been bothered enough to run online update). I unfortunately don't know how to make the package so that the buildservice would build it also for something else than openSUSE/SLE, but people who'd want to use it with other distros can either take the patches from it or find the right howto for multidistro packages somewhere at the openSUSE wiki. And, I should also note that Exmap seems to work only on 32bit, on 64bit machines it aborts due to some error that I haven't really looked at.

Back to the memory wasting issue. This is not the first time something outside of KDE made its memory usage look bad, and there is again the same solution - the proven kdeinit hack. It is still somewhat useful even on its own (0.7MiB RAM saved per process on 32bit, that's with a debug build without limited symbol visibility though, so I don't know how much it is in practice), but it can save much more when it comes to these workarounds. Kdeinit pulls in the library once, lets it mess with memory once as it wants, and then it is shared by all applications launched using kdeinit.

Well, that is at least the theory. It first needed fixing kdeinit, as that has never really worked in KDE4, broken by about 4 independent changes (and yours truly being guilty there too). Probably time to slowly start looking at performance again. By the way, just in case somebody would feel like measuring KDE4 memory usage and comparing the numbers with the previous benchmark, that is of course not the right way. Measuring both KDE3 and KDE4 on the same system might be interesting though (and I am not the one going to do that - it is not difficult, but I don't have the time).

For after making the theory of the workaround match the reality, see the picture. Now there are more processes "using" the library, but all those launched from kdeinit share the 11MiB waste just once (and 'sole mapped' is zero for them, unlike the other case where the waste is per process). There's not much to do with X, and also KWin is excluded from kdeinit, since there is the other __GL_YIELD=NOTHING nvidia hack for compositing and that clashes with this hack. Still, I thereby claim the achievement of reducing KDE4's memory usage for the plain desktop by about 33MiB (which was enough to fit whole plain KDE3 desktop according to the old benchmark), try to beat that!

I recently noticed that although I have already talked about using KDE4's KWin in KDE3 or any other window manager in KDE instead of KWin, there is one thing missing in the mix: Using KWin without the KDE desktop.

Yes, perfectly possible. KWin is actually a KDE application like any other (well, more or less) and so just like other KDE applications it can run in GNOME, Xfce or even standalone, as long as the KDE libraries are available. And while some people may wonder about the sense of this, some apparently see it.

So, let's have a look at how to use KWin in GNOME, Xfce or standalone. As the title suggests, there will be some resistance, but that can be overcome .

KWin standalone: Let's start with the simplest case. And also probably the least likely. It is possible to use KWin alone without any desktop, just like it is possible to use for example WindowMaker or FVWM. However, unlike those, KWin is not very suited for this task, as it is a pure window manager. Meaning, it provides only window management features and not additional elements of the desktop like the taskbar, desktop background or application launching. So while such usage is possible, I don't expect many people would try it, without additional tools to provide other desktop functionality. If you try it, it's simple - just launch KWin, that's it.

KWin in Xfce: In Xfce KWin must replace Xfwm4, the default window manager. This is done by running 'kwin --replace' (e.g. using the Alt+F2 dialog). After this, you will have Xfce with KWin running, in order to get the same setup the next time, you also need to save the session - start logout and in the logout dialog make sure to check the option for saving the session. Now, the next time you start Xfce, it will launch KWin as it window manager ... except that, it won't (IMPORTANT!). Current stable Xfce versions have a bug that will make its session manager crash during startup with KWin. This problem is supposed to be fixed with the 4.6 beta versions, but if you have 4.4, you will need a workaround before you first start Xfce this way:

You should run a script with these contents before Xfce is started. I'm not sure what exactly is the Xfce equivalent of KDE's $KDEDIR/env/*.sh , but if you use Xfce, you should know better anyway. If you don't know, adding these commands to .profile in your $HOME should do too.

KWin in GNOME: This one will be ever a bit more complicated. It appears that there is no UI way of replacing Metacity in GNOME and that choosing a different window manager is done using $WINDOW_MANAGER. So you can for example add 'export WINDOW_MANAGER=kwin' to your $HOME/.profile file. Next time you start GNOME, it will use KWin instead of Metacity. However you will probably soon find out that for whatever reason Metacity is not only GNOME's window manager but also shortcut manager - Alt+F1 for opening the desktop menu of Alt+F2 for the run dialog will not work anymore. There appears to be no simple way to trigger those from command-line, but at least OpenBox people have already run into this problem, so why not reuse their solution with thanks? After you install OpenBox (openSUSE users can get it from the X11:/windowmanagers repository), there will be also tool gnome-panel-control. Now you need to bind Alt+F1 to command 'gnome-panel-control --main-menu' and Alt+F2 to 'gnome-panel-control --run-dialog'. Bad luck with GNOME's tool for custom shortcuts I guess, given what is written above, so you can try with XBindKeys - please refer to its documentation for how to configure the shortcuts and how to make it autostart in GNOME.

That's it. In all three cases, if you need to configure KWin, run 'systemsettings' and find the relevant option there. Since KWin is usually seen as a component of KDE, you will need to have a look in several places. Shortcuts are together with other global KDE shortcuts in 'Keyboard&Mouse', functional settings are in 'Window Behavior', desktop settings are in 'Desktop' and the looks are in 'Appearance'. You can access most of KWin's settings also by right-clicking any titlebar to get KWin's popup menu.

Something more I think I should mention: I've normally used KDE4's KWin in KDE3 session (as in, for normal real work, not just testing) and I couldn't notice any performance impact because of this mix (perception, I don't normally use my computer with a stopwatch in one hand ). The overhead of running KDE4's KWin in KDE3 should be about the same like when running it in Xfce or in GNOME. After all, you can do 'zypper install kde4-kwin' or an equivalent and try it yourself.

As you might have noticed, KDE 4.1.3 has been released, codename "Change" (in line with other C- codenames recently, as a kind of a joke on all those people who fail to see that still writing comments with overuse of K after 10 years of KDE's existence can only be a sign of brain damage). Not many changes in KWin there though, the changelog part for KWin has just one change worth mentioning. But that is not the case for users of the openSUSE KDE:KDE4:Factory:Desktop packages, which are the packages that will be also used for openSUSE 11.1. This is because they include a special KWin branch, which contains both backports of various new features from other KWin developers from SVN trunk (Lucas' blog keeps track of many of those) that cannot be backported to the 4.1 branch by KDE rules but should be stable and safe enough, and new features developed specially for the needs of openSUSE11.1/SLED11.

The most prominent of these is probably the fact that compositing is going to be enabled by default if possible - that is, if you install openSUSE 11.1 on a system capable of decent compositing without explicit installation of drivers, you will get desktop effects out of the box. And since decent compositing should not include the infamous cases of getting a nice white screen or detailed view of how things are painted one after another, KWin has a couple of various clever or crude tricks that should ensure it works. KWin compared to Compiz has the design advantage that it can handle gracefully working without compositing, and so far it seems these checks do their job pretty well (and if not, you should complain, that is what beta releases are for). Selecting where to enable compositing by default was also based on the list of systems where people have reported success with running composited KWin.

Another, well, significant feature is the desktop cube. Let me get this one straight - there are only two things I find good about the cube:

1. It gives users who have problems grasping the concept of virtual desktop a nice way to imagine how it works (except that in reality it does not work that way at all, but who cares if it works for the user).
2. The cube has somehow become the symbol of desktop effects and so KWin simply has to have it to be taken seriously by some people (and of course it makes it possible to enable it for 5 minutes to impress people stuck with MS Windows). Guess why I ended up including the cube image inline as the only one.

What I especially don't think the cube is very good for is to be actually used - I always get motion sickness when I have to use it for a short while and I don't think it makes it easy to find things either (and that was just with the default 4 desktops, what would be with my usual 12 or if I enabled options like the transparent cube). Nevertheless there are enough people who find it useful, so why should I be stopping Martin from implementing it, right? So we now have the cube, hurray (or something), not enabled by default, but that is easily changed in the configuration.

The PresentWindows effect includes backport of a more natural layout of showing all the windows and it can be also configured as the effect to be used for the Alt+Tab functionality. The updated DesktopGrid has not been included due to some minor problems with it, and the 4.1 version has distortion problems with non-square desktop layout, so we have default number of desktops now again 4 like in upstream KDE (I've never understood what was the point of having only two, not a big difference to having just one). For people with a different layout the effect at least tries to keep the presentation as square as possible. Options to select which effect is to be used for Alt+Tab or desktop changes are now two simple comboboxes, with a third one globally affecting all animation speeds for those who find animations acceptable only if they are fast.

As for technical backports, there are several features worth mentioning too. I have backported fullscreen window unredirecting, new handling of idling, and the 'Keep window thumbnails' handling, which when set to 'Only for shown windows' makes desktop switching as fast as with Compiz (since it technically makes it handle the window contents the same). To my knowledge KWin's performance should roughly match that of Compiz and if it does noticeably worse on some setups that should be usually a case of the drivers being bad.

There seem to be already a number of happy users of KWin's compositing, so, well, I hope it will work well for you too. Maybe you will not even notice at first .

Last item is not about KWin but rather Compiz - the option to select the window manager to be used with KDE is in the more logical Default applications module in Systemsettings and, when Compiz is selected, the Configure button will launch simple-ccsm-kde, which is simple-ccsm equivalent that does not drag in all the g* dependencies. For people who still have a reason to use Compiz instead of KWin.

Dear LazyWeb ... erm, I mean DoItYourselfWeb. As you may or may not have noticed, KWin now again defaults to compositing enabled, if possible (the self-check will possibly still need polishing a bit, but that's why it's enabled by default now, right; and the little trick for detecting too bad performance needs some testing too). This is true for both to-be-KDE4.2 KDE trunk and to-be-openSUSE11.1 packages.

One of the problems with that is that there are a variety of graphics cards available out there and only very few of those in here. Meaning I actually have no idea if and how well it works e.g. with Intel i915 or Radeon X1300. Currently the logic for enabling compositing by default is 'is it nvidia or intel driver, if yes, try to enable, otherwise sorry' (yes, no ati/amd right now).

So, just in case you'd feel like, I created a page at techbase with a list of cards, and you can add yours. The instructions are at the top. A nice list would be actually very useful to me. Thanks .

Zero as when it does not work. And that's sometimes zero fun. There is a plan to enable compositing by default in openSUSE11.1 when possible (just like e.g. Ubuntu already does), so I've been again pondering the idea of enabling KWin's compositing by default in SVN too, just like it was in pre-4.0 times. The "when possible" part is of course the problem. Even openSUSE11.0 is already ready for compositing, assuming proper driver is correctly installed, but there still may be possibly some problems with some setups, and of course upstream KWin does not have the comfort of knowing the underlying stack is configured properly.

KWin is actually quite robust when it comes to handling compositing failures, so if it detects a problem, compositing will just get disabled and KWin will keep going on. And here the "detects a problem" part is the problem. For example if AIGLX is not working, this may result in the only-white-windows-with-shadows bugs, which is caused by the X stack losing window contents somewhere. But, strictly technically speaking, from KWin's point of view everything is working correctly (at least I don't know any error detection of this), it's just that the user does not see what they should see. How is one supposed to detect that? KWin during setup checks X errors, OpenGL errors, various required X/OpenGL functionality, tries to detect driver used, the compiz-manager wrapper script has blacklists and whitelists and whatnot, and yet this all is sometimes not enough.

And then, while thinking about this, I got this absolutely ingenious and yet awfully simple idea (aren't all of them like that?). With compositing, the compositing manager uses Composite extension to get window contents as a pixmap, then binds an OpenGL texture to it and then renders the window to the screen using the texture. So, how about simple trying if this actually works? Trunk KWin now has a compositing selfcheck that creates a very small window with few basic colors painted in it, then it's handled just like described above, and finally the screen contents from the window's position are read back as a pixmap. If it matches the original, good, if not, bad luck, sorry. It's so awfully simple that I'm really surprised nobody has done that yet. With this, many of the other checks are just secondary, just try if it really works, that's it.

That's the theory so far. It works for me, my normal working setup logs "Compositing self-check passed." in the debug output, one setup that until now has been problematic without KWin detecting that now gives "Compositing self-check failed, disabling compositing." (and saves me pressing Shift+Alt+F12 once ). However, the question is, does it work properly also for everybody else? If somebody has a setup where compositing is broken but current SVN KWin still keeps it enabled, please create a bugreport (also, if somebody for some strange reason happens to be unfortunate enough to have now compositing disabled because of this check even though the system is otherwise capable of it, please complain too).

If there are no problems, KWin will get compositing enabled again by default soon, and I'll consider a 4.1 backport (not enabling by default there though). It would be still nice to find some way to detect whether the performance is sufficient or whether it's too poor for compositing, but there the ingenious simple idea has been eluding me so far (since KWin can't really just measure FPS during startup, for several reasons). Also, there is still the problem of X crashing, drawing artifacts and other nasty problems, but having a hack for that would be a real black magic mastery.

Oh, and BTW, just in case somebody still feels like using something else than KWin in KDE , the UI option for switching window managers has been moved to a somewhat more logical place, that is the 'Default applications' control module.

I got a bit bored this weekend (ok, ok, I had to do a lot of cleaning and so and needed an excuse) and had a look at two performance related things in KWin. First was fixing the CPU usage problem caused by using vsync, now that Thiago found out why I couldn't reproduce it (I build Qt without Glib support, it just messes the backtraces up). Interestingly it was code that was supposed to save CPU that by mistake caused the increased CPU usage. Oh well. Second improvement is unredirecting fullscreen windows - that is, if a fullscreen window is not covered by something else, such as a game or a movie, that window is excluded from compositing and allowed to draw normally. This lets it draw at the full speed and should also help with avoiding tearing. The simplest way to see this is to maximize a glxgears window and then compare its reported number of frames to also making it fullscreen using Alt+F3/Advanced/Fullscreen. I could post a video, but it would look quite similarly to the previous performance joke. This one is for real though. The small downside of unredirecting a window is that it no longer has a preview e.g. in Alt+Tab (could be handled with some more code, but not a very high priority now, unless somebody else feels like doing that or I get bored some other weekend).

This should mean that right now KWin's performance should generally match that of Compiz. Maybe a little difference here or there (I haven't really yet optimized the common paths that much), but I'm currently not aware of anything that should make a big difference. Some time back I even improved the so-called 'keep window thumbnails' functionality, which with the 'shown windows' option should match in practice what Compiz gets with viewports, i.e. previews for windows on inactive virtual desktops and fast virtual desktop switching.

So I hope people now won't have to write many rants about this or even complain about KWin to Compiz people (well, I guess I can see that as some kind of payback for them calling an internal Compiz utility 'kde-window-decorator' and making us get a load of bugreports about it ). Those screenshot just show increased CPU usage, i.e. the vsync bug, nothing interesting about them, except that you can't see the without logging in (really interesting that forum implementation, I mean, what kind of an idiot puts captcha on a search form?). I hope that person could be satisfied now. And, as for the KWin design flaws mentioned in the reply, I've already taken care of that:

Me (notice the evil look): You screwed up KWin's design!!!!!
Matthias: Oops, sorry, did I?

No, just kidding. KWin's design is still about the same like in KDE2.0, and, apparently, it still just works. I can't see a problem with not having been designed from the group up for compositing, something that nobody even thought about at that time, yet getting there when the time comes. I, on the other hand, think it may be interesting to watch how something that was designed that way tries to work also without. Especially if somebody at Novell decides that I get to watch that very closely (may happen, isn't life fun?). Don't think I'm bashing Compiz however, as it is a great CM, it just has a little while to go (or, to put it differently, it is never a very good idea to talk about work of others and not know much about it... ).

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.

[image:3477 size=original]

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.