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.
Strange. I'd guess there is something wrong with the settings :-(
I also have this, running on a old Geforce4 64MB.
Running with Xgl I have much smoother visual effects, but CPU usage goes sky, with AixGL there is almost no extra CPU use, but the effects runs with a bad framerate.
remember, these techniques are just very immature yet. X.org doesn't really have the proper infrastructure, and it'll take years to reach the quality Vista has (yeah, it's weird, but they got this right). Or Mac OS X.
Though I expect a lot from Kwin ;-)
Is a better infrastructure in development?
And what happend to Xegl? I think I read somewhere that David Reveman is still interested.
I'm running an older ATI Radeon 9200 card, one of the last ones with specs released so it has solid freedom software support. With it, CPU usage is *HIGHLY* dependent on rendering choice. The old XAA rendering is incredibly CPU bound with composite on. The new EXA rendering is MUCH MUCH more efficient, and while there were stability issues earlier on, with xorg 7.2, EXA with composite enabled is about as stable and CPU efficient as XAA without.
So, if composite is eating your CPU cycles for lunch, try turning on EXA instead of XAA, and see if that helps. With the xorg native Radeon driver, it's a setting in the xorg.conf graphics card "Device" section, as so (rats, plain text is still eating the indents, and the markup won't work either, but they aren't absolutely critical, so...):
Option "AccelMethod" "EXA"
To switch back to XAA, a simple # at the beginning of the line comments it, returning xorg to the old XAA default.
I'm also using an ATI Radeon 9200 with the open source driver and my experience is exactly the opposite. With AIGLX CPU usage is very high with EXA and it is somewhat OK with XAA. Maybe some other configuration options influence the performance.
I think kwin could take some things from metisse - it has some pretty neat ideas too worth integrating into kde directly
Okay, that's it - i'm definately switching to KDE 4.0 ;)
I think KWin should take the best ideas from existing solutions like compiz and metisse.
It does :D
The Desktop Grid effect is AWESOME, and definitely seems way more useful than the beryl/compiz Cube (which, frankly, is only good for eye candy). I think it will make virtual desktops much more usable. Great to see that Kwin is doing sensible and exciting things with these capabilities!
Desktop Grid is already available in compiz, it's called "wall" plugin...
and was available in metisse before that...
Absolutly 100% agree.
I use Beryl on my work PC, so I'm in front of it a lot. The cube is fun, but a bit annoying when you've got stuff on many desktops. This approach look vastly superior. Plus, you aren't limited to 4 desktops!
umm... the compiz cube isn't limited to 4 workspaces, you can use as many as you like. seriously though, why all the cube haters?
Another useless candybar but one that I like none the less.
YAY for wobbley windows!
As always The Road... series delivers an excellent run down. I really like how you pointed out that Kwin is mature, whereas compiz and beryl are still the new guys (yeah beryl is sweet, but it is crash city sometimes). I totally support the home team solution.
Since other people use this as a place to deliver critiques I have a small one. The desktop grid should scale so that the virtual desktops are still in the same aspect as they are on the monitor. Maybe the addition of black bars like on a widescreen movie would be a good solution.
Can't wait to fire up 4.0! You guys rock.
> The desktop grid should scale so that the virtual desktops are still in the same aspect as they are on the monitor.
Exactly! I find the squashed appearance of the Grid sort of disturbing. Maybe they'll fix it. Some good looking implementations of the grid are from:
Mac OS X Leopard, called "Spaces": http://www.apple.com/macosx/leopard/spaces.html (Wow! They're catching up! :P)
Speaking as an exclusive KDE user I am very disappointed. I see this as nothing more than fragmentation. I know it was said that there were technical issues in working with the existing Compas+Beryl project. However I can not really see anything but ego here and it is bound to promote some sort of Desktop War Revisited. I do note the great pains that they have taken to let people jazz up their desktops and that must be some great code. However it is my opinion of ego, fragmentation and a new desktop war happening.
"I know it was said that there were technical issues in working with the existing Compas+Beryl project. However I can not really see anything but ego here and it is bound to promote some sort of Desktop War Revisited."
"I know perfectly valid technical reasons were given, but I'm going to go ahead and spin it as a petty, purely political issue, with nothing to back that up whatsoever!"
He won't be the first - I'm sure when this hits osnews or similar websites, there'll be a lot of opinions like that. However, I'd like to restate that those wishing to use compiz/beryl will be able to continue doing just that. We're not locking you into KWin or anything -- just like you can use the gimp in KDE or Amarok in Gnome, or KDE with Enlightenment, or any other random combination of Unix apps - they should all play nicely with one another as we do work hard on cooperative standards. KWin isn't inventing anything new that'll lock you out of using alternate window managers :)
Back up? No Back up? The Gnome vs. KDE history is my back up!
You mean the fact that we now have two excellent desktops (one more excellent than the other obviously ;) is a reason for not working on similar projects?
Gnome and KDE evolved in very different directions. If we only had KnomE it would be a compromise, and lots of people would lose out on their optimal environment.
I think the fact we could have one perfect desktop instead of two excellent desktops is disturbing. Besides two desktops means two learning curves.
I can't force anyone to agree with me thou and everybody's free to create as much desktop environments as wanted (after all, we praise freedom, don't we?).
"I think the fact we could have one perfect desktop instead of two excellent desktops is disturbing. Besides two desktops means two learning curves."
What makes you think that we could have one "perfect" desktop? KDE and GNOME are very different in many ways. People who prefer GNOME obviously prefer the approach taken by GNOME, whereas KDE_users prefer the KDE-way. How would you suggest combining the two so that you can keep the strengths of both desktops, while not forcing users to suffer the weaknesses of either?
Many KDE-users like KDE because of the features and tweakability it gives them. Many GNOME-users prefer GNOME because is simple, clean and streamlined. In many ways the two approaches are diametrically opposed. How would you combine them? In the end you would get compromises and "designed by a committee"-software that would leave both KDE and GNOME-users frustrated.
What about developement? KDE-developers like Qt and C++. GNOME-developers like GTK+ and C. Again: how would you combine those?
Anyone who suggest that combining KDE and GNOME would result in one perfect desktop, is quite simply deluding himself.
No what I mean is this. I applaud Compas and Beryl for reemerging because they are a better product as a whole. No need here for two halves of a company to do mostly the same things. It is the same with Kwin. I think it would be better served if Kwin did their own branding of Compas+Beryl.
Simply put the reemerging of Compas and Beryl avoided a useless desktop battle. Falling in lock step is pointless and so is endless forking.
I honestly do not care about wobbly windows, cubes, or whatnot. I care about a fast and stable way to handle my 12 Desktops. I care about Expose-like features. KDE is my work environment. I want my WM stable and proven and supporting all the fringe cases I might run into without me noticing as much as a "whoops". I want my WM integrated with KDE in such a way that I do not even notice how nicely they play along.
I do not need one of the "good looking" new kids on the block when my productivity and fun is at stake. But I do appreciate the tons of work hours and tons of code which went into a WM which I do not even think about any more. KWin is more mature and has more features I care about than compiz.
Thanks, kwin developers.
"I think it would be better served if Kwin did their own branding of Compas+Beryl."
it has nothing to do with branding or ego. the technical reasons have been explained repeatedly, and they are purely technical. the first thing we (kde) did when trying to decide what to do was to look at the options and play with each of them; they included:
- writing a new WM from scratch (there were even experiments here)
- adapting compiz/beryl (either wholesale or just the compositing technologies)
- improving kwin
each was given a lot of thought and testing. there is no perfect solution, agreed, but there are better solutions and worse solutions where "better" and "worse" are judged in relation to the effect on our userbase.
and remember that our userbase includes schools in "third world" countries, banks and governments in the "first" world, hard core hackers, hobbyist computer users, SMBs, 'regular' home users .......
point is, Beryl and Compiz are the new projects, they should've worked with the existing projects. They didn't because they just wanted to show what's possible, not rewrite the current windowmanagers.
Now of course, that's exactly what they're doing. They should've stayed at being a research project, not try to be a real windowmanager.
In any case, the most important problem here is: Compiz and Beryl don't have a real plugin structure, or api. If they had, we wouldn't have a problem - Kwin could adopt the API, and they could share plugins. Instead, Compiz and Beryl are a mess, in terms of plugin-structure: there is none. The plugins just hook into the basics of Compiz and Beryl, and if you have a different base, they won't work.
This is stupid, non-secure, unstable, un-portable and user & developer-unfriendly. Not strange for research projects, of course, but a pity for projects trying to be taken serious.
If Compiz/Beryl doesn't have a good plugin API, I understand why KWin didn't aim for compatibility with them, but that doesn't prevent them from working together.
Did the KDE developers try to work with Compiz/Beryl to develop a good plugin API? If I wanted, could I write my own window manager that would work with KWin plugins? Is there a specification somewhere for this plugin API?
If not, the not-invented-here syndrome has at least something to do with this.
I really hope KDE developers aren't trying to lock-in KWin plugins to prevent other projects from using them, but I wouldn't be surprised if they were.
Umm, the source code is available... so there's no way to, as you decribe, 'prevent other projects from using [the effects]'... however, many of the effects are done using Qt APIs, which would probably need to be ported anyway if another window manager wanted to use them. Which they can do easily, since, once again, the source code is available.
In fact, according to Seli, many of KWin's composite's technology comes from reading the source code for 'glcompmgr', a much simpler composite manager than Compiz/Beryl. So, reinventing the wheel this is not... at worst, KWin is guilty of porting some code. :)
"The Gnome vs. KDE history is my back up!"
you're taking two non-comparable sets of events and trying to compare them. =)
Then you should complain to the Gnome people. They were the ones who fragmented the desktop in the first place, since before that only KDE existed.
The issue isn't as clear-cut as that. GNOME was actually the first Free desktop since Qt was non-free at the time.
But KDE itself was already free software and advanced enough to predict it would never go away. Creating another desktop from scratch was the worst possible solution to the problem. I personally believe the whole Qt thing was only used as a pretext to start up Gnome.
> But KDE itself was already free software and advanced enough to predict it would never go away.
No it wasn't. KDE was far from advanced at the time of GNOME's inception (August 1997).
> I personally believe the whole Qt thing was only used as a pretext to start up Gnome.
You are sadly mistaken. The licensing issues were very, very real. Before the relicense under the GPL, Qt (and by extension KDE) were non-free software.
Before GNOME was started, intense efforts were made to resolve the Qt licensing issue. One such effort was to rewrite Qt and clone the Qt api via the Harmony project. When those efforts failed, there was little else to do but to start a competing project.
Harmony never failed, it was never given a chance to succeed. KDE was announced in 1996, and Gnome was born on 1997. There was no way that in only one year something like Harmony could be built. Some people just wanted very badly to start their own desktop project.
The reason Harmony failed was that the KDE project was perfectly happy with Trolltech (and the Qt licensing assurances made by Trolltech), and would therefor not commit to Harmony. At the time, there were also grumblings from Trolltech about Harmony which cast an ominous shadow over the long term validity of the project, and their chances for success. This uncertainty is similar to what detractors of Mono point out as a sore point of /that/ project today.
There is no conspiracy. Licensing was the main reason behind the creation of GNOME.
/me still doesn't know what was really wrong with the QPL... the spirit of the license is sound, even if it has some minor conflicts with the GPL...
"I know perfectly valid technical reasons were given, but I'm going to go ahead and spin it as a petty, purely political issue, with nothing to back that up whatsoever!"
Those 'perfectly valid reasons' were things like "It doesn't handle the fringe cases like transients" yet there's still no concrete example given of a specific application that fails. I can't imagine adding the same fixes that were in kwin's code base to theirs for whatever application we've still not heard of that fails would be that hard. I REALLY doubt it would be anywhere near as hard as duplicating that much of Beryl's functionality was. And yet, it happened, and we march on to massive duplication of code as usual rather than people bear working together on small things.
The technical reasons were little things like, oh, the fact that they don't _have_ a plugin api to follow. Beryl just exposes all its internals.
So KDE should start using GTK instead of Qt?
Using crappy technology because of political reasons it's Gnome's game, not KDE's.
"I can't imagine adding the same fixes that were in kwin's code base to theirs for whatever application we've still not heard of that fails would be that hard. I REALLY doubt it would be anywhere near as hard as duplicating that much of Beryl's functionality was."
[~/kdebase/workspace/kwin]>(find . -iname "*.cpp"; find -iname "*.h") | xargs cat | wc -l
[~/kdebase/workspace/kwin/effects](find . -iname "*.cpp"; find -iname "*.h") | xargs cat | wc -l
So the sum of "that much of Beryl's functionality" is about 11% of the codebase of kwin. You seem to think that adding an expose clone is some kind of momentous achievement that must have taken masses of hard code to duplicate. In fact, all it took is this:
A mere 700 or so lines of code, a lot of which is boilerplate. That neat grid?
A mere 500 or so lines of code. That spiffy "live thumbnails on the taskbar" effect?
About 100 lines.
I'd also remind you that kwin has been under development since KDE2.0, whereas the entirety of the effects you see here - whose development was most definitely not the sole focus of Lubos, Rivo and Phillip - has occurred since October of last year.
I really don't don't know how Free Software developers do it - being constantly criticised based on the thoroughly misinformed guesses of random strangers all day long would probably make me quit in disgust. The fact that they don't makes me respect them all the more. Keep it up, ladies and gentlemen - your work is much appreciated :)
> I really don't don't know how Free Software developers do it - being
> constantly criticised based on the thoroughly misinformed guesses of random
> strangers all day long would probably make me quit in disgust. The fact that
> they don't makes me respect them all the more. Keep it up, ladies and
> gentlemen - your work is much appreciated :)
I agree. I guess you really have to have a "thick skin" to endure all this false claims...
So, a big thank you to all devs!
"I really don't don't know how Free Software developers do it - being constantly criticised based on the thoroughly misinformed guesses of random strangers all day long would probably make me quit in disgust. The fact that they don't makes me respect them all the more. Keep it up, ladies and gentlemen - your work is much appreciated"
Okey on that you got me. Clearly I am coming at it from a end user and New user perspective. As I said I was glad I was very glad to see Compas and Beryl join forces again, for reasons I have made clear.
Gnome and KDE have came from different areas and methods and that is all cool. Now however they have been agreeing on common APIs and that to me is a win for all and that with in their own idea of how each is wanting to do things.
I still can not get passed how commercial developers will not know what to do with now not only two different sets of window manager APIs that are not completely merged but now three (two??) different 3D compastating options.
All very confusing and I watch this stuff constantly just like the rest of you.
I'm not sure how likely it is that commercial developers would want to write a plugin for beryl/kwin.
If you mean general composite stuff that an app would use, then that is totally standard, and is done by the x server.
Any gnome app using composite will work in kwin and vice versa. Everything is standard except the plugins, and that's a tiny amount of the code.
Thank you for giving specific information. As much as I might tend to agree with the original author, it is sad that I had to dig this far into the comments to find specific information about what was implemented. From an initial reading of the article, it DOES sound like an ego issue. Thank you, Anon.
*clap* *clap* *clap*
I enjoy being a bystander, well said sir!
"I really don't don't know how Free Software developers do it - being constantly criticised based on the thoroughly misinformed guesses of random strangers all day long would probably make me quit in disgust. The fact that they don't makes me respect them all the more. Keep it up, ladies and gentlemen - your work is much appreciated :)"
Yeah as far as I can tell, Free Software people take a lot of shit all day long. Just from reading the planet and peeking in on some blogs you can see what some KDE devs have to put up with! I suppose KDE really is a labor of love.
OK, let's look at your question. Kwin has existed and been worked on for > 6 years. Beryl/Compiz has existed for < 2 years. So why do you think it would be quicker to add kwin features to Beryl than it would be to add Beryl features to kwin? "Let's see: 6 years of polish vs 2... Which would be easier to add to another project? Why the 6 years of course!" wtf
And yeah, I'm sure my year counts are off. Point was kwin has far more years of work behind it.