Submitted by Just when you thought fancy effects on Linux desktops started to get remotely understandable, focussing on Aiglx/Xgl with Compiz, a fork of Compiz is announced: Beryl. This is the logical continuation of the popular compiz-quinnstorm branch, used by many Ubuntu users. “During this summer, and during the last few weeks, some major additions were done in compiz-quinnstorm, bringing a whole new decorator, cgwd, which was designed to be fully themable, and a new settings backend, csm, which intended to drop most of the gnome deps – there were other reasons for this, but this is not our current subject. Consequently, we reached a situation where it’s quite impossible to come back.” The main reason is general unwillingness to work with and unresponsiveness to the developers of the -quinnstorm branch from the official Compiz guys.
Will some of these hacks be accepted as mainstream some day, or has this already happened?
Edited 2006-09-19 15:26
Seriously, you Linux-fans can complain all you want about evil companies not providing drivers and MS controlling the world, but until you stop changing things every two weeks, Desktop Linux will be a toy for geeks. We all want the best solution, but sometimes it’s a compromise. Now Red Hat will use AIGLX, Novell XGL and all geeks (presumably)Beryl. Good luck gaining support from hardware companies there…
Edited 2006-09-19 15:28
Hamman –
Did you even read the post? If you read it, I think its a good move.
This is how great software is made, it takes time (so does the MS way I suppose) but what you have in the end are very stable and solid product.
Take Apache, MySQL, Gnome, FireFox, Samba, and many other OSS project that may have forked a very long time ago, but after a while, the best project is left standing. The users are better for it in the long run.
Edited 2006-09-19 15:37
of course it’s a good move, if the compiz guyz aren’t cutting it, others will take the job. In the end one or two standard will rule them all.
It’s a good thing for users.
“Take Apache, MySQL, Gnome, FireFox, Samba, and many other OSS project that may have forked a very long time ago, but after a while, the best project is left standing.”
Non-OSS people are usually communists, so it’s not a big surprise they don’t understand competition.
What a bullshit post.
If it’s compiz or Beryl or whatever, it doesn’t matter to hardware manufacturers in any way. There are at least two layers between compiz and the hardware driver.
AIGLX and XGL are on way to be merged and Compiz and Beryl are just a kind of window managers, nobody complains that we have kwin, metacity, *boxes etc etc.
nobody complains that we have kwin, metacity, *boxes etc etc.
Yes, all these freakin’ save-[Joe Sixpack][my grandmother]-the-headache-of-learning-new-in-five-minutes usability zealots… sorry, I meant Ubuntu users. :-p
Um…you should know that this has nothing at all to do with hardware companies or drivers. It’s a compositing framework that sits over the hardware interface layer.
Also, I’d suggest not starting off a comment with something like: “Seriously, you Linux-fans can complain all you want about evil companies not providing drivers and MS controlling the world…”. It makes you seem like a Windows troll or something.
Make that software companies(typo, sorry). ISV’s are gonna look at Linux and say “so you’ve got two [whatever XGL and AIGLX should be called], two desktop enviroments, two toolkits and two compositing managers. And that’s with a marketshare of a few tens of a percent(or whatever it is now). Yeah, great platform…”
If speaking the truth mens coming through as a windows troll, I’m prepared to pay that price.
Beryl is not an alternative to Xgl or AIGLX. Xgl and AIGLX are the technologies which implement the features necessary to do whizzy 3D desktop effects. *In themselves*, they don’t do any whizzy 3D desktop effects. The component which actually does the whizzy 3D desktop effects is the window manager. There are several window managers capable of doing whizzy 3D desktop effects. compiz is one of them. beryl is a fork of compiz. Clear now?
That would merely give them one less excuse to justify Linux being a flop. And excuses are all that those poor Linux zealots have.
For what it’s worth, the 3D desktop extensions all operate on top of GL. The hardware manufacturers have nothing to support but GL. And for that matter, the different setups are equally as irrelevant to software developers save for the ones writing effects plugins for the desktop.
“The main reason is general unwillingness to work with and unresponsiveness to the developers of the -quinnstorm branch from the official Compiz guys.”
If this is the case, fork away. Having a seperate project rather than a patch branch is less confusing for everyone.
3D desktop Linux is in its infancy and hopefully the competing solutions will converge or be eliminated until only the best is left.
Edited 2006-09-19 15:34
hopefully the competing solutions will converge or be eliminated until only the best is left.
"ohhm, yeah, can you give any good examples of when that actually happens in the open source world. My guess is that developer, user and media attention will help generate lots of independent projects, which will hopefully all be a bit different so as to cater for different users and needs. Project convergence = stagnation in the open source world, if anything.
Edited 2006-09-19 23:22
Normally I’m all for forks and choices, but in this case I think having a single “desktop glitzer” would really have helped adoption. Especially when it seems like there weren’t any solid reasons for a fork (besides “not invented here” syndrome). I could see if XGL was abandoned or something, but it is still in the development phase, and seems counter productive to fork now. Almost like a case of the forkers saying “Well if they don’t want our help, we’ll take our toys and go home!”.
Xgl is not forked as I understood it, only compiz is, am I right?
Xgl, AIGLX, and Xegl are three different methods of supplying the underlying compositing support to the desktop environment.
Compiz, Xcompmgr, and Beryl are composite managers, kindof like window managers (though they usually have a seperate program such as gnome-decorator or cgwd to manage window borders/themes). Metacity will have native compositing support in the near future from what I hear.
Yes that is correct, Compiz/Beryl are just the window managers, XGL is the underlying software that provides all the openGL infrastructure. Both Compiz and Beryl share XGL in common and can also make use of AIGLX if you tell the wm’s to do so.
As for the merits of quinns packages, yea they are prone to crashing and have many glitches. SO basically, i use metacity. Talk of a stable branch is music to my ears if they can achieve this. But there have been bugs in the works that they havnt been abl to track down since the compiz release, quinns been hoping on upstream to solve them … so they definitely have allot of work for themselves i think, but i am quietly optimistic. And i think greater community openness is a good thing and will bolster the projects activity.
Edited 2006-09-19 20:12
The quinnstorm branch started as a patch to the official compiz to include some experimental plugins made by the comunity but in the later times it has become a window manager for itself.
As compiz developers didn’t realize that themeable windows was a good point in modern desktops, the quinnstorm branch developed GCWD (Gnome Configurable Window Decorator). Later, just because the complains about using gconf to configure compiz (as it declares to be desktop-agnostic) it changed it’s configuration system to CSM (Compiz Settings Manager) so since then all the tools made for the official compiz were incompatible with the quinnstorm compiz. I personally think that the fork was actually the first version using csm, now comes the official confirmation.
Anyway, for me it doesn’t matter because in the end, Metacity and KWin will implement their own effects and we are going to use the official window manager of the Desktom Manager of choice.
As compiz developers didn’t realize that themeable windows was a good point in modern desktops
That does not seem like a fair evaluation to me. To quote from the TODO file of the gnome-window-decorator:
* Plugin interface
* Plugin with SVG-based theme support
* Plugin that supports old metacity themes
cgwd made a very rushed and somewhat buggy impression on me. While it is good to have, I would not consider it a complete superset of gnome-window-decorator just yet. In any case, this is hardly a problem since window decorators are replacable already.
Sure, eventually, KDE 4 I believe will have its own composite management within (kwin). GNOME 2.16 does with metacity (turned off).
But, in the meantime, beryl does give us an idea as to what can be done.
Compiz will be superseded by compositing Kwin and Metacity window managers in the near future. They will have their own unique effects native to the desktop environment.
I believe KDE 4.0 will include an experimental compositing Kwin with effects that will further improve as the 4.x series progresses?
I’m not so sure with Gnome but maybe they’ll do something to Metacity in Gnome 2.18 or 2.20?
This is what i call Chutiyapantis of the OSS world….i am sure my Indian friends will understand my post;)
Metacity has had “official” (though still experimental) compositing effects since 2.16 which was released something like a week ago I think.
I believe KDE 4.0 will include an experimental compositing Kwin with effects that will further improve as the 4.x series progresses?
Kwin for KDE 4.0 already has the compositing support, the planned upgrade to kcompmgr was more or less merged into kwin.
The struggle they have now, at least from one of the dev posts I saw a month ago or so, is that they need coders for the graphical effects beyond the transparency and shadows KDE already has today.
Seems to me, that with this project officially forking and becoming independent, it might be worth the kwin or plasma team exploring the possibility of interoperability with some of the plugins and add-on features. The KDE devs could leverage some of the OSS development going on with Beryl, and Beryl would gain much more visibility and support, ideally leading to increased development aid and bug tracking/patching while still maintaining independence from any one entity or distribution. Win – win.
By the same logic I wonder if the metacity devs can’t do the same thing for Gnome? Maybe taking it a step further Beryl could become some sort of a freedesktop standard for desktop 3d effects that would be environment/wm agnostic, requiring only some sort of interface between the windowmanager and Beryl. Might also prevent the windowmanagers from becoming bloated and overdeveloped since they don’t have to sacrifice stability and possibly performance by re-inventing the wheel to produce the effects natively.
Of course, that’s a completely uninformed opinion coupled with a healthy dose of wishful thinking since I have absolutely no idea of what would actually be involved to make that level of compatibility happen. But it’s nice to think about.
Maybe taking it a step further Beryl could become some sort of a freedesktop standard for desktop 3d effects that would be environment/wm agnostic, requiring only some sort of interface between the windowmanager and Beryl.
Compiz is already an essentially desktop-agnostic system. The effects and features are developed independently of the desktop integration plugins, so you don’t need Beryl for this. I’m actually quite fond of the compiz plugin system and I’m wondering if this system won’t be superior in the long run to the “monolithic” approach of metacity and KWin.
Compiz is already an essentially desktop-agnostic system. The effects and features are developed independently of the desktop integration plugins, so you don’t need Beryl for this. I’m actually quite fond of the compiz plugin system and I’m wondering if this system won’t be superior in the long run to the “monolithic” approach of metacity and KWin.
Absolutely agree on the last point, it would be nice to see metacity and kwin take a modular approach. Frankly I don’t really see anything lacking on my desktop with quinn/cgwd vs. when I was running kwin with kcompmgr, it’s just as stable and useable. I’d really like to see Gnome and KDE work with Beryl on metacity/kwin rather than re-invent it, otherwise users will be forced to choose one way or the other rather than possibly have the best of both worlds.
Edited 2006-09-19 18:11
I don’t know how well that could work. Beryl/Compiz plugins are written in C, so you’d need to be able to load them in C++ and they’d need a total rewrite as plugins in compiz are raw xlib programmed, no KDE, no GNOME just X11 programming.
Upstream compiz has not been responsive to ideas and patches from several developers working on the QuinnStorm branch of compiz. Elitest attitudes and an unwillingness to work with others is what caused x.org to fork from XFree86 and look how much better x.org is now.
Beryl has at least a dozen developers working on various parts of it and the community is really helping bugfix and test new parts of the code. This project gives Linux the potential to become the best looking desktop on the block. With the genie and sidekick effects from the new animation plugin, it already looks better than OS X.
Long live Beryl!
Upstream compiz has not been responsive to ideas and patches from several developers working on the QuinnStorm branch of compiz. Elitest attitudes and an unwillingness to work with others is what caused x.org to fork from XFree86 and look how much better x.org is now.
The only forks I am familiar with are x.org from XFree86, Firefox from Mozilla/Netscape/Whatever, and XBMC from XBMP.
All of which, after some time, are better than they were before.
XBMP was awesome, then I read about XBMC coming out as a fork. I ran it and it was horrible and didn’t work half the time. Then 6 months later, it was better than XBMP ever was.
Forking is almost allways good, it brings competition and inovation. For example – XFree86 and X.org
XFree86 was forked because of a license change. X.Org is the new de-facto standard and now used by virtually every Linux distribution, BSD, and Solaris.
X.Org 7.x is also better with it’s completely modular design.
Maybe they have a better idea.
Well, I certainly admire the objectivity:
general unwillingness to work with and unresponsiveness to the developers of the -quinnstorm branch
Well, that seems a bit one-sided, in fact the whole article seems a bit one-sided. I have no idea who any of these people are and I am not a party to either side, but I am certain that there is another perspective to this issue.
However, this is almost by definition how Open Source projects work. People see a potential new product, and either create a new project, or fork an existing one. The more developers at work, and the more new ideas created, the better. So this event is almost certainly a net gain.
If someone wants limited choices, they should find a small distro and stick with it. Research, innovation and variety are wonderful things. If you don’t progress, you die.
There are some people who think that the only purpose for Open Source is to provide free-as-in-beer replacements for their favorite Windows programs. And that all programmers should drop what they are doing and work slavishly on free word processors, free email, and free bookkeeping packages. Those things exist. Job done. Let’s get away from the cheap and mundane and make something new.
I’ve been using Quinnstorm for a few months now.
Anyone who cares about compositing on the linux desktop should see this as a very good thing. The Quinnstorm package has had more features than Compiz since its inception. And recently, a lot of new features have been added to configure and personalize the various effects.
Many of the tools are “hackish”, and unprofessional but Quinnstorm has the most features out there, provide great support at #xgl @ irc.freenode.net.
Rather than write their own compositing effects, Metacity developers should work with the Quinnstorm people to better integrate the projects.
Many of the tools are “hackish”, and unprofessional but Quinnstorm has the most features out there
That’s the same impression I got when I tried the Quinnstorm packages. When I initially tried the original XGL/Compiz combo, I was surprised by how stable and well-thought out the individual features appeared. I did not get this impression with Quinnstorm/Beryl at all. This fork makes sense to me, so we can have a testbed for experimental features and hacking, as well as a more sober original version.
I agree. Upstream is about 7x more stable than quinns fork
I disagree. What’s your gfxcard?
@ Hammman. You’re confusing XGL with Compiz & Beryl. XGL is the accelerated X server, it’s completely new whereas AIGLX builds upon (and adds 3D acceleration support) existing X server technology. Compiz is a Window manager, like metacity or AMI, except it controls an accelerated desktop. Beryl is a fork of Compiz. Since many of the additions, bug-fixes, and new features failed to be folded into Novell’s original Compiz, a fork became necessary. The open source works is it’s all about choice. Some distros will choose XGL (or AIGLX) / Compiz classic, some will choose XGL (or AIGLX) / Beryl. The most feater-rich, easy to configure variant will by natural selection, become the most popular and eventually the two competing projects will merge into one. Stop acting like Microsoft’s “all your base are belong to me” tactics are better. To illustrate my point, you need only have a look at the process that has produced Vista. Enough said.
I’m not sure that I have ever touched the vanilla compiz. Getting rid of the gconf dependencies was something which I had been advocating ever since I first had to change settings with gconf-editor. I hate gconf-editor.
Apparently, I’m a Beryl man now.
That doesn’t make a lot of sense… gconf-editor is not meant as a configuration utility for users. The only reason you _had_ to use it, is that things are still very much work in progress and experimental. As a user interface, I find the CSM utility even more horrible to be honest. What I don’t really understand is why they had to drop gconf to support csm, I thought the plan always was to support multiple configuration plugins.
That doesn’t make a lot of sense… gconf-editor is not meant as a configuration utility for users.
…
What I don’t really understand is why they had to drop gconf to support csm, I thought the plan always was to support multiple configuration plugins.
The lack of a gconf dependency means that I, as a KDE user, can run compiz-quinn without requiring the Gnome DE to be installed alongside it. I’m not saying that was the intent, but I’m grateful for it none the less. Seems a little ridiculous to download a DE to use a “desktop agnostic” window manager.
Besides, if gconf-editor isn’t meant as a config utility, why wouldn’t they seperate the config into something less agnostic that could have a proper config utility written around it?
I think you missed my point.
The lack of a gconf dependency means that I, as a KDE user
That lack of gconf dependency is a good thing, but why not keep it for GNOME users? An alternative KDE configuration plugin has always been on the TODO list.
Besides, if gconf-editor isn’t meant as a config utility, why wouldn’t they seperate the config into something less agnostic that could have a proper config utility written around it?
You can just as well write a proper configuration utility using the gconf settings. In fact, that’s the whole point. Gconf is not about the UI but about management (lockdown for example) and easier development. gconf-editor is just a convenience tool for developers and geeks who want to access the settings database directly.
… this means I’ll be able to install the original compiz on Ubuntu, and not the hacked version that is officially on the repositories at the moment.
After using both compiz and compiz-quinn I have seen the difference
While the new cgwd is good, in general quinns work has been buggier. While david may have a hard time accepting patches, quinn seems to let everything into her tree, compiz-quinn is terribly unstable.
Finally, saying
a new settings backend, csm, which intended to drop most of the gnome deps – there were other reasons for this, but this is not our current subject
Is a cop out. The real reason for this fork (in my opinion) is that they implemented an unstable configuration backend with and abhoration for a GUI and have since been to stubborn to rip it out………
Truth be told, this fork is only happening because the Novell guys never changed their closed source tendencies. They developed XGL in a box and then said hey, we’ve done it right for you, so don’t worry about participating. Well, they did the same thing with Compiz for the most part, but unfortunately it got out in the wild and did a little mating. Anyone that has really used the quinn packages knows that they are incredible, and she and her band of merry men have pushed Comiz to were it should be with all those great plugins. Yeah, the current release may be a little buggy for some, but that’s what happens when you remove the gnome dependencies once and for all. They have releases almost 3 times a week with bug fixes and speed improvements. Her configuration tools and skining api’s are great. If Dave isn’t careful, Beryl is going to end up replacing Compiz all together, because those plugins that the comunity keep pumping out really make all the eye candy usefull. It’s one thing for the Novell guys to talk about code quality, but if your not giving the people what they want, they will go elsewhere. That somewhere else for me is definitely Beryl, becuase it’s a great example of the power of open source development. Oh, for anyone thinking she just a lone rebel, you very much mistaken, becuase their are many developers pumping out plugins and fixes daily. http://www.Compiz.net
Edited 2006-09-19 20:05
Give me stability and cohesiveness (vanilla) over features and instability (quinn) any day…..
Just my experience thought, disregard it at will..
Thats not my experience at all.
I’ve been running quinns version for many months now, and I think it’s very stable. (both on aiglx/xgl and with intel i915/nvidia)
For Ati users there is still some problems but that is due to the buggy drivers from Ati, so don’t blame that on Quinns verion of compiz.
On the contrary however, I tried the original compiz version on Suse 10.x and that one had a tendency to crash from time to time. Oh, the irony.
Instead of all this Compiz forking for Beryl, what I think should happen is that Compiz itself should be changed simply into an API for other window managers. This way people can create plugins for said API, then just implement hooks into it. For example, create a libcompiz, then simply have metacity-compiz and kwin-compiz compiled with support for this library, which in turn will allow compiz-plugins.
The window manager itself is more than likely never to be installed by default by any of the major distributions anyhow, unless of course someone wants to create an entire DE out of it. KDE already has Kwin, Gnome has Metacity, etc. These are the ones that are the default for those projects, Compiz will never be their default. But saying that the development of it is a waste would be a bad.
Instead of doing a full fork and having a name change (which just adds more confusion to everything else, I think people were just starting to realize the difference between XGL and AIGLX) they should just have a compiz and compiz-svn or cvs. As I think Novell’s intention with Compiz was just to demo their XGL anyhow, and was really never intended to become a full fledged Gnome or KDE Window Manager replacement.
It’s especially going to be a moot point when the nvidia drivers and ATI drivers finally release full support for the required extension(s) for the Compiz stuff.
All in all though, good luck to all these projects. I do miss having transparency effects sometimes when I’m trying to do some work, but other than that, I still use just Metacity with Gnome.
Well this is good. It seemed like original compiz authors (David Reveman and Novell) didn’t have much patience to work on this as they tend to focus on tech stuff. They didn’t create a huge community either. This should be handled by (younger?) people with some artistic skills and then it will result with a good plugin API and ultimately with extreme eye candy and new user experience.
Small OT (a question): I can’t remember a name of the kernel patch I recently read about somewhere. It is supposed to speed up boot process by sequentially ordering data on the disk, read during the system init (patch also has some hooks into kernel ext3 driver for example). Can anyone remind me, please?
Someone said my name!
Well, sort of.
If you’ve been following compiz for a while then you should read my posting:
http://lists.freedesktop.org/archives/compiz/2006-September/000423….
I posted that in order to get an idea as to why Novell is not being more open. Instead, I got an answer that was polite, but full of ‘well, i’ll try to do this and that’.
It doesn’t cut it, Open Source progresses when there’s action not when you don’t have things out in the open in the first place (See Xgl mess).
Right, now Beryl is the best of the bunch until KDE4 and GNOME have their composite effects in order which no doubt will come. But until then, Beryl is sort of a demo of what a 3D desktop *can* do. Surely those effects can be reimplemented in GNOME or KDE4. Everyone will win
Shawn.
Ive seen more people complain about quinns reliability since the beryl fork was announced then ever before. I find this a little crazy. Ive used quinn’s packages since the first one, over the span of 3 different laptops and never had a single problem! It has worked well on all of them despite using a shared ram ati or nvidia card. I think it must depend on which distro someone is using, on Ubuntu its awesome but on the same box in gentoo I had horrible problems (on both stock and Quinn) so if your havong issues and your not using Ubuntu switch!