Submitted by “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.”
Some reader posted a link to the dot.kde.org comment section that points to a video which shows a couple of the composition effects in one go and also shows those effects can be enabled and configured.
http://www.youtube.com/watch?v=4WBLlc6xCQ4
Uh, that would be me (the article’s author
). I had the article go to press just as Rivo created that video, so I missed adding it in the original text. It’s a good video though, as it basically combines four of the videos I showed in the article, as well as the config dialog I used in my screenshot. 
He also has an avi version of it online, high resolution, 16MB, here: http://freehackershosting.free.fr/rivo/kwin-compositing-070529.avi
…however, in an effort to reuse code, would it be possible to have kwin reuse Beryl/Compiz plugins? It seems to me that some of the effects (such as Scale) are duplicating the work that is going into “that compositing manager”.
I imagine that the two pieces of software have very little in common, and that this would be a challenge, but it would benefit from future Beryl/Compiz developments.
(Then again, I’m not a programmer, so do feel free to tell me to shut up…)
There was a lot of discussion about that, but the developers eventually decided that it wouldn’t be possible. Apparently the way things work are quite different and it would have been a large undertaking to get it working. I’m sure they would accept patches, though…. I guess that’s my way of telling you to shut up, huh? 🙂
Edited 2007-05-30 22:22
Yeah, I figured as much. Well, as long as one doesn’t get in the way of the other (i.e. if I decide to use Beryl/Compiz, that the KDE effects can be turned off easily).
If you use Beryl/Compiz, then KWin won’t even be running and there will be nothing to interfere with.
I wonder how much work the effects really take. I get the impression that they are fairly simple, or at least fairly simple to port if you’ve already got one in Beryl. In that case, I don’t really see the need for directly using them. If it does take a lot of extra effort, though, then that could be an issue.
The KWin guys looked at the Compiz/Beryl plugin interface and saw that it, very pragmatically, hits the WM’s internals directly. To support Compiz/Beryl plugins, KWin would have needed an adaptor layer to make it look like C/B to the plugin. This would have been more work than recreating the effects as native KWin Composite effects.
It’s basically the same formula used when deciding whether to use C/B and extend with KWin’s features or to bring C/B’s effects to KWin: which is less work?
…however, in an effort to reuse code, would it be possible to have kwin reuse Beryl/Compiz plugins?
I think we’re just going to have to face the fact that Beryl and Compiz are never going to be intimately integrated with the major desktops enough to be reliable enough for everyone to use.
There are always going to be annoying bugs that we see in Beryl and Compiz that come out when you start using them on a daily basis, and they’re only going to have an adequate amount of testing when a window manager is more intimately integrated with the desktop, as Metacity and KWin are.
…is if someone put together a compositing effect standard before too much more work goes into competing projects. fd.o, im looking in your direction….
Well, nothing to look at then.
freedesktop.org is a collaboration platform where developers of desktop related projects can work together in a neutral context.
It doesn’t magically enslave developers to create specifications, it rather offers communication channels such as mailinglist for “external” developers to propose and discuss specifications and eventually host the drafts, final versions and/or reference implementations
of course it doesnt, i never said that it did.
It also has a place for those external developers to suggest new specifications, it is called the XDG list. FD.o doesnt magically enslave external developers to spontantiously come together to come up with a spec, they talk about it in the mailing list.
This is why i said what i said, this is exactly the kind of thing that should get an fd.o spec asap before too much duplication of effort happens.
Well, you made it sound like you’d expect some mythical entity “fd.o” to come up with a specification or shared implementation of some sort.
Since fd.o doesn’t do this by itself but, as I said, offers a collaboration platform for interested parties, your kind of directed request ” fd.o, im looking in your direction” seemed mistarged.
That’s what I wrote, isn’t it?
You even quoted it.
User smitty wrote:
So, unless this is some kind of misunderstanding or misinterpretation of what happend, it looks like the discussion about a common base has already happend but wasn’t successfull due to not having enough common ground.
I think it was just an internal discussion, which doesn’t necessarily mean fd.o couldn’t come up with a good spec. It just means they wouldn’t be happy with taking the Compiz implementation directly and would need to come up with some 3rd solution in between the two. Or maybe there really isn’t enough common ground, I don’t know.
The FD.o mailing list I mentioned in the parent post is the forum where such things are decided. That list has prominent members of the major DMs, which is why FD.o stuff actually gets implemented. They are not a structured organization, but they are not simply for hosting either.
from the main page:
I was talking about the discussion part of it.
Actually, you didnt write that, you jumped down my throat saying it was basically the sf.net of specifications. It is that, but it is a forum for discussion of new specs too.
Very perliminary discussions have happened about it. This is new technology, it would be a good idea to take a step back and look at how it fits into the big picture before everyone goes off implementing things their own way. It may be decided that the whole thing should be DM specific, or that parts should be DM specific, but that there should be commonalities to play friendly with others, or that it makes no sense to have compiz/beryl/kwin all doing more or less the same thing, and instead to make an outside project to handle the whole thing.
Actually I did, but maybe you do not read anything I write, not even the parts you quote?
Lets have a look at this posting of yours:
http://www.osnews.com/permalink.php?news_id=18000&comment_id=244254
You quote from my previous posting “it rather offers communication channels such as mailinglist for “external” developers to propose and discuss specifications”
To which you reply “It also has a place for those external developers to suggest new specifications, it is called the XDG list.”
And now you tell me I didn’t already write that before?
Maybe a little fragment by fragment comparision will answer this:
– I wrote “it offers”, you wrote “it has a place”
– I wrote “mailinglists”, you wrote “XDG list”
– I wrote “propose specifications”, you wrote “suggest specifications”
Now, I am not an English native speaker, but those look pretty much equivalent to me.
Why?
It has been shown that creating those plugin effects is quite easy once you’ve the WM. I can’t really see what’s the problem people has with different window managers implementing different, incompatible effects. We’ll have different WM that look different. Yes, so what?
This is not really one of the problems that fd.o usually solves…fd.o is for useful standards, like cut© and drag&drop. But what’s the point in standarizing the plugin interface for the internal composite effects??? It looks as stupid as saying that the menues that konqueror/epiphany/firefox show should be standarized, really.
Edited 2007-05-30 23:47
The menus in konq/epiphany arent standardized, but the way to make the application menus, and how to make shortcuts are.
I don’t see how this is dumb, instead of having two sets of plugins with popular ones being duplicated, we would have one set of plugins without any redundant work being done.
I disagree. The main work goes into the algorithm (shaders and other effects) that get applied to the surfaces. Making a cross-desktop plugin framework would make it harder to make the plugins because they’d need to be tested more. It’s better to take a wait-and-see approach at this stage of the game, since these frameworks are still very new. It’s always better to standardize on something that is out there and has been “proven,” which is not where I feel that compiz and beryl are yet. Also making a plugin framework that is coupled so tightly to an app really constrains that apps future evolution.
I, for one, will be happy to have a desktop effects config tool as well as a compositer that doesn’t crash all the time on my Kubuntu…
The most telling thing from this whole demo was the magnification effect. I’m not sure if it’s just the low quality of the youtube video, but it looks like the items in KDE are vector-based, so they didn’t appear to pixellate when magnified. Maybe this isn’t implemented yet, but getting magnification working right to produce hard-edged vectors from apps that use Cairo would be the holy grail. This is where Windows is at with Avalon apps…
Even if they don’t have that working, KDE is an awesome project and I really hope they relegate Gnome to the dustbin in the near future.
+1
I was just going to post a comment along the same lines.
Whichever will have that feature will be the winner for me – I tried beryl, and the magnification effect is quite ugly, even though most of the desktop is vectorial – and with svg icons on the way, that’s even more true. I hope a vetor magnifier will also scale svg images in Firefox…
OT : What I’d really like is a feature for Firefox allowing to upscale a whole page that way, that would save the problem of garbled text that appears when one increase the police size. At the moment, if you have a high dpi screen (like on laptops) that can be quite a pain.
Edited 2007-05-31 10:05
Being vector based would only help if the magnifying effect were done at the rendering level.
The magnifying effect of composite managers is applied after application rendering, thus it can only work on the image data
I’ve got to agree that KDE is awesome (it’s certainly what I use), but I’d be very surprised if Gnome ever got relegated to the dustbin. There are just too many people who use it and like it. As useful and unifying as it would be to have a single, major window manager for Linux, the sheer variety in people’s tastes and preferences makes it highly unlikely. Just the same, it wouldn’t hurt my feelings any if KDE became dominant enough that Gnome was relegated to the dustbin. KDE 4 will likely at least be a step in that direction if the Gnome folks don’t come up with similar improvements.
/EVEN/ if the Gnome project didn’t become viable any more (and that is a /massive/ ‘if’) it will never be relegated to the dustbin. There’s far too many die hard users out there.
Besides, Gnomes appeal to many is it’s simplicity with functionality, so I don’t really see much conflict there.
The most telling thing from this whole demo was the magnification effect. I’m not sure if it’s just the low quality of the youtube video, but it looks like the items in KDE are vector-based
For KDE 4, and with Qt 4 underpinning it, that’s certainly the aim.
Maybe this isn’t implemented yet, but getting magnification working right to produce hard-edged vectors from apps that use Cairo
As I understand it, Qt (and KDE) doesn’t use Cairo at all yet, basically because they’ve needed to come up with their own technology for this called Arthur. I would imagine that this is because Trolltech have to produce something that works extremely well cross-platform, and to their own timescales and deadlines, but they’ve left the option open for Cairo to be a back-end for Arthur in the future.
This is where Windows is at with Avalon apps…
Windows and Vista is perhaps a touch further on with all this, but whether a lot of the technology Microsoft has in Vista and Avalon will make too much difference to an end user is another matter. Quite why we had Windows.Forms is anyone’s guess.
KDE is an awesome project and I really hope they relegate Gnome to the dustbin in the near future.
I don’t think it will relegate Gnome to the dustbin, because let’s face it, people have been saying this in either direction for years.
However, I feel that they have a far greater chance of producing a quality desktop with all these effects that people want, that work reliably, because they work very hard on having an underlying infrastructure they can really rely on. Qt helps them out big time there as well. It takes all the guesswork out for application and desktop developers.
actually, there is already a cairo backend for arthur. As arthur can also use OpenGL directly, I don’t see the use, but well – it’s there…
Man, what’s going on with the KDE fans lately?
First we have a story about the new Gnome roadmap taken over by people going “but KDE can do that now, Gnome/GTK is crap!” (and cunningly ignoring the things that Gnome can do that KDE can’t).
Now we have this blatant trolling (which I’m sure, if it said about Gnome relegating KDE to the dustbin, would be quite correctly modded down) at +5.
I’m a Gnome user, but I don’t have any problem acknowledging the good bits of KDE. What I’ve seen of KDE4 so far seems interesting, even if the hype from the the KDE fans borders on the ridiculous. (Hint: codenames don’t make something cool. All the interesting things are, or will be, in Gnome too. Calm down.)
But KDE users seem to have a large inferiority (superiority?) complex when it comes to Gnome, in much the same way that BSD fans do with regard to Linux. Any excuse to do down the “competition” must be taken, and criticism isn’t tolerated. What gives? Why not, y’know, live and let live?
Correctly modded down? Do you feel personally insulted or something? I never knew that Gnome has a personification which goes by the handle “tristan.”
I’ll say it right off: I’m not a huge KDE user or a frequent linux desktop user at all. When I’m using linux, it’s mostly from a tty. I don’t care about the outward appearance of the *DEs that much (after all, I’m mostly using VI anyway). What excites me about KDE is the clean architecture that it embodies. It doesn’t seem to have the jumbled dependencies of the Windows userland or the hackish underpinnings of Gnome (this is by reputation… I haven’t yet spent any time looking at the Gnome source, but I have seen kde and Qt from a development perspective).
KDE is generating a lot of excitement right now, seems to have a tasteful architecture, and appears to have a good philosophy that encourages layering and proper reuse. And it has a good chance of showing up on Windows. Can the same be said for Gnome?
better than the compiz stuff. Outside of the blow up feature I thought the effects showed more promise of productivity than just eye candy.
At any rate I say good job.
One of my annoyances with Beryl/Compiz is that my old slimline machine doesn’t support pci devices that are compatible. I can use Voodoo3 cards with it, but they are about as powerful as it gets.