KWin, KDE's window manager, has been around since KDE 2.0 (replacing KWM in KDE 1.x) and has grown to be a mature and stable window manager over the years. For KDE 4, however, there were a few people rumbling about visual effects, and perhaps KWin was feeling a little envious of its younger cousins Compiz and Beryl. While these new effects have created a lot of buzz around Linux and UNIX, long-term KDE users have wished they can enjoy the effects of Compiz/Beryl while still having the tried and tested window manager that is KWin. As a result, for KDE 4, KWin has received a huge graphical upgrade, with composite and GL support. Read on for more details.

KWin has implemented effects in a way that allows a number of different rendering methods to be used, depending on your specific combination of hardware and drivers. These features have brought KWin rapidly into the era of dazzling eyecandy, along with some pleasant surprises on the usability front. This effort has been spearheaded by Lubos Lunak (a man known for his efficient code) and his team, with special mention to Rivo Laks and Philip Falkner for their contributions.

Effects are disabled by default at the moment, although that may change before KDE 4 ships, and distributions may decide to alter this setting anyway. When enabled, the effects are designed to degrade gracefully. If GL is not available, KWin disables GL effects but still allows Composite effects where possible via XRender. If XRender is not available, it falls back to plain X, running in the same fashion as the present KDE 3 version. To get the full array of effects, you need to have a video card (and driver) that supports AIGLX, XGL or use the proprietary Nvidia driver.

Once the effects are enabled, it's simply a matter of choosing which effects you'd like to activate. So far, Rivo Laks has been working on the effects plugin selection interface (see the screenshot below). The new plugin selection widget shown is making its way into various parts of KDE - it does automatic dependency checking, so once the dependency tree is known, it will intelligently enable or disable dependent plugins. This widget is also showing up in other parts of KDE 4.

(as you can see in the image, this dialog is quite new - less than a week old - and is missing all the icons...)

Lubos has been periodically blogging about the effects that KWin is now capable of, and has recorded a number of videos showing them off. Since video capture on my system is rather chunky, I will present his recordings instead. So, without further ado, I present some of the more popular of his flash videos, hosted by YouTube. If you are interested in more, please visit his YouTube User Page

The Present Windows Effect - a very useful effect that falls into both eye-candy and usability categories...

The Desktop Grid Effect - those familar with the Cube effect may note that this is not quite as flashy, but probably more useful. Doesn't mean there cannot be a Cube effect for KWin though.

This one shows the above two effects, as well as the Alt-Tab thumbnails, but it shows that the effects work great, even when the windows contain active videos.

Zoom Effect and Magnifier Effect: some accessibility related features that everyone may find useful, depending on your specific needs.

Effects like this one make people go "Wow". The first part of this video features the Fall Apart Effect, which basically has a window blow up. It's amazing how well this effect can be demonstrated in a low quality flash video...

Aside from Lubos, many of the new effects and underlying core components were programmed by Rivo Laks and Philip Falkner. They are responsible for many of the effects you see in the videos, including the Present Windows Effect, and the improved Alt-Tab dialog. There have been a number of contributions from others as well, and they are always looking for new and interesting ideas. In addition, KWin for KDE 4 builds on the already existing KWin version which has had dozens of people contribute to it over the years.

The window decoration shown above is called 'kwin3_crystal' and is still set as the default in SVN. It is simply a port of the existing KDE 3 Crystal window decorations, however, a new KWin window decoration is still in the works for KDE 4 - it hasn't been made the default yet, so I haven't been featuring it. When it does eventually become the default, you'll be sure to hear about it here (and likely in Danny's KDE Commit-Digest as well...).

KWin for KDE 3.x implemented a very simple composite manager, allowing simple effects such as window transparencies, fading menus, shadows, and so forth. The code was not too complex, but the infrastructure was not in place to seriously extend the effects to GL powered goodness. When the KDE 4 development series opened, it was seen as an excellent time to rewrite some of KWin's internal structures in order to support such effects. There were initial considerations of implementing support for the existing Compiz and/or Beryl system of effects via plugins, but there were technological hurdles that prevented this. I won't go into the technical details as to why this decision was made, however, it is important to note that KDE 4 will still work with Compiz/Beryl should the users choose to use that software instead of KWin.

Additionally, while KDE 4 will be supporting a number of platforms with libraries and applications, KWin is one of the applications that will not be making the switch as it is inextricably tied to X. This should be considered to be a Good Thing(tm), as it ensures that KDE will always be the best looking when used with Linux/UNIX, and hopefully it (and related KDE Workspace technologies, like Plasma) will remain a unique benefit of using a more open operating system.

KWin promises to ensure that KDE get the graphical boost it needs to keep the eye-candy folks happy, while providing new and usable features for the desktop environment that would not have otherwise been possible. Yet, it maintains the rock-solid foundation that a long history as an integral part of KDE has provided. It will still work (with reduced levels of effects) on any system that KDE 3 ran on, so no-one is left out in the cold. It is already the default for KDE 4 in SVN, and will be showing up in future beta releases.

On a personal note, I've found that KWin on my system was dropping down into XRender mode due to some X settings I need to fix, but it has been perfectly stable for me over the last two weeks. In fact, every week when I'm rebuilding KDE 4 to write these articles, I am more amazed at how quickly it is becoming stable and useful. If you are interested in testing it out for yourself, check to see if your distribution has packages available. I am aware of the existence of at least one live CD (where you don't have to risk messing with your system) that is available at the KDE Four Live website. They update the Live CD every few weeks, and currently has the KDE 4.0 Alpha 1 packages. Additionally, if you are brave enough to test the Composite features, and are having problems, have a quick look at the Composite HowTo.. If you have problems, please report bugs using the the KDE Bug Tracker by selecting the KWin program, and the "composite" component.

Until next time.

Comments

someone else filled in the details for you, if you look above there is a list of things kwin does right today that beryl/compiz doesn't. i try not to spend more than a minute or two writing replies here, so apologies for not being more thorough.

"I REALLY doubt it would be anywhere near as hard as duplicating that much of Beryl's functionality was"

well, it is. in part because the proper window management takes a -lot- of testing under all kinds of conditions and compositing tech is far more self-contained of a problem space: it either works or it doesn't. neither is trivial, but one is faster to get through. the work compiz/beryl have done also shows the way quite nicely; they deserve massive kudos for that.

we have a known good solution that our userbase absolutely relies on. beryl/compiz doesn't work for the entirety, majority even, of that user base. ergo the chosen solution.

btw, this isn't a kde thing. metacity is doing the same thing and, as i understand it, for the same reasons.

Yea! There's only one window manager needed! Oh - even more! There's only one desktop environment needed! And - uh! Oh! We only need one operating system! So why don't we all use Windows?
Why do people waste resources by making OSX, BSD, Linux, Symbian, ...?

Maybe competition and choice is a good thing? Maybe without competition there wouldn't be evolution (see Windows Vista as an example).

And anyway, if you really wnat to blame someone for creating "fragmentation", blame the author of compiz who started a new WM and not implemented it in KWin or Metacity (since it was a Novell employee).

The simple point is: Compiz was a research project. It is now indeed duplicating stuff found in current windowmanagers, but that's THEIR waste of time.

The lack of a plugin infrastructure in compiz makes it impossible to directly re-use their plugins (though we can and do port code and ideas from them). And windowmanagment is much larger than compositing, so it makes more sense to add compositing to a windowmanager than a windowmanager to a compositor.

While I like these video's, there is one thing that Kwin still cannot do: really maximize a window! By this, I mean that the border around the window really disappears, and I can, finally, scroll in konqueror without having to look at the right edge of the screen to see if my cursor is on the scrollbar. I could just flip my mouse to the side and scroll.....
sigh.
well, you can allways hope..! :-(

I use Plastik window decoration and it hides the border at maximalization. (Try to scroll with the mouse in xterm on the border and on the edge after maximalizing.) Maybe the problem is with the application? (E. g. Konqueror itself has a border.)

A window can be in one of four states
1. minimised
2. "restored"
3. maximised
4. full screen.

I think what you are asking for is a way to reach the fourth state. Well, the window menu, in the "advanced" submenu, has a "full-screen" option. I set up a shortcut for that (alt-enter - there's no default shortcut, however).

One way to set up a shortcut is in the kde control center, region and accessibility -> keyboard shortcuts. In the first tab (global shortcuts), in the "windows" group you have the "full screen" entry.

No matter what you do you (disable "Allow moving and..." or F11 fullscreen) you still end up with a couple of pixels right to the scrollbar.
You should be able to just move the cursor to the right edge of the screen to use the scrollbar. Right now, this is not possible.

Here is a little Screenshot of a maximized Konqueror (the active window in the back) and a normal Konqueror (the little window in front). As you can see, there is no border beside the scrollbar of the maximized window, but a gray at the small window.

Use window specific settings to force the window to be displayed with the scrollbar at the edge of the screen. The only option that seems to work is 'force' while for 'apply initially' and 'remember', the setting is not applied on new windows for some weird reason...

Although KDE support d&d (drag and drop) but KWin fails KDE applications by making it impossible to do drag&drop.

because the focus changes to the window as soon as the mouse button is pressed (clicked and held), which makes it impossible to do drag and drop in KDE.

whereas, in windows, when the user releases the mouse button only then the "focus" shifts to the window.

Try for yourself:

1. open konqueror file manager or Dolphin (first window)
2. maximize the first window
3. open another instance of konqi or dolphin (second window)
4. but do not maximize it.
5. Now, try dragging a file from the "maximized" first window to the "unmaximized" second window.

6. as soon as you click on the file in the maximized window the focus is given there and lo and behold! your whole idea of drag&drop is destroyed.

it was reported in KDE 3.3 by me, and this thing is
fixable.. just use "release to focus" instead of "click to focus."

> it was reported in KDE 3.3 by me, and this thing is
> fixable.. just use "release to focus" instead of "click to focus."

With KDE 3.5, there is some advanced configuration for this things. I does'nt the English name for modul, but it must be something like 'windowattributes', where you can also configure the click-behavior.

This kind of drag and drop works with tabs in Konqueror, which has a nice smart behaviour if you drag an item over the tab, so it works as expected. It's also less work (e.g. to manage the windows) than having multiple windows.
Sadly, the developers are reluctant to implement these tabs known from Konqueror in Dolphin.

hehe, that's exactly what my self-created taskdock do. I think with kde4 and plasma+kross, there will come a huge wave of alternative task bars and docks, because, with scripting-lang this is really easy.

a focus can rise the window or not, most people expect that to happen, but there are several WM that allow it... fluxbox is one of then, it have a option "click to rise"... as soon you click on a window, it rises (the focus is another option), so disabling this will allow one to click and work on a window that is below another one... i maybe wrong, but i think i saw one option in kwin to not "rise on focus/mouse button" when i used it

Actually, I prefer the "focus follows mouse" policy. That way, there is no problem with drag and drop (as opposed to bloody window$, which bring the window to the top when it is clicked. No way to simply _activate_ a window, while keeping it behind, where it was the whole time :(. Now THAT'S annoying.)

I just saw the wavy-windows effect (via youtube-dl and mplayer) and I rather liked it, since it would make a great screensaver.

Many of the people there seem to just think "not what I know" or "doesn't work for what I want it for, therefore it's useless" or similar, and I think that the videos should get some really fair feedback.

In the first screenshot... Why is the "Configure window effects"-field wider than the field (the one with "PresentWindows", "blur" etc.) beneath it? A tiny nitpick, I know, but I think that details like that are quite important (and quite easy to fix).

Hi, I'm very impressed with the progress KDE 4 is making - keep it up!
Just wondering about KDM (the theme manager from http://www.kde-apps.org/content/show.php?content=22120) - apparently it is being integrated into KDE 4? What's the latest? Will the theme manager be as easy to use as GNOME's (i.e. drag-and-drop the theme file into the manager and it's ready to go)? How will it interact with kwin_composite and plasma? I really hope theming becomes easier with the next KDE release.

kdm is not a theme manager, its kdes login application. the link you posted is only used to choose a theme for kdm, not kde.

also, kde3.5 allready has a theme manager (to be found under appearance and themes in controll center) that makes it possible to to configure desktop-background, colors, widget theme, icons, fonts and the screensaver with one file.

so it works exactly like gnome. the only difference is that gnome users tend to produce more "theme-files" than "widget-theme-engines", and kde users do the opposite.
because widget-engines are compiled programs, they should be installed by the packagemanager of your distribution.

I'd be happy if they just made it easier to configure KDM from the text files. I still haven't been able to get KDM to do multiple sessions on different local X servers. GDM does this quite nicely with a little editing of the config file.