“All technical reasons (alternative configuration system, alternative decorator, xinerama…) for this fork are incorrect and I know that at least Quinn Storm is aware of this, based on a phone conversation we had last week. With a few notable exceptions, most of the code I’ve seen going into what is now beryl is not high quality code that would be considered for compiz.”
For anyone that tried both versions it’s no surprise that quinn’s branch includes not so high quality code.
In more interesting news, the gtk-window-decorator from compiz CVS now supports metacity themes.
beryl looks much better and has more effects.
For those who don’t like this, why not stay with your plain metacity?
I’ve stuck with DavidR compiz and it’s smoother than cgwd/Beryl as well. To many Vista themes in quinnstorm, i’ll stick with metacity support in compiz.
(*speaking of quinn’s version*)
Not only low quality of code but the default settings are horrible.
I remember once installing compiz and it had the shadows turned pink … or another install where the minimize plugin was on and it crashed compiz upon starting.
I wish they would focus more on bugs then on features at the moment since they got a couple nice things going on.
Does Compiz have drop shadows and also some other effects that Deryl have?
Yes and but not as many plugins, only the stable ones.
How do I enable drop shadows in compiz?
They enable by default when all the plugins are loaded, use the compiz-manager to enable it.
here is a example http://gandalfn.wordpress.com/howto-compiz-aiglx-on-edgy/
SlackerJack,
I note your howto says:
For those people using NVidia should continue to use Xgl server. compiz-aiglx don’t work on this card !
You might update this to mention the beta 9625 driver available from Nvidia. It *is* a beta driver, of course, but Nvidia is getting there. You can get it here: http://tinyurl.com/atcs3
It’s not my howto, just the packages I use in Edgy.
One point that’s overlooked is that not everyone is running Gnome.
Sure, compiz + gwd will run fine on a KDE desktop, but then so will metacity, but that’s not the point. In both cases you pretty much need to install gnome and rely on gnome utilities for configuration. Adding support for metacity themes to gwd sort of underscores where Dave R.’s desktop priorities are.
And that’s fine, nothing wrong with that.
But then there’s nothing wrong with the community creating their own project with a themeable decorator and one that’s not bound to the gconf registry editor.
I’ve been running beryl from svn for a few days now, works very well with the new nvidia driver, without requiring Xgl. The configurator tool is a little rough around the edges but works well. And being able to tweak the style settings appeals to my KDE nature.
Beryl is hackish, I won’t deny that. But from what I’ve seen, issues are acknowledged and dealt with, and they’re really encouraging input and contribution. But it’s easily as stable as my prior experience with compiz, and doesn’t require 100MB of libraries installed as dependencies. Beryl is a little friendlier if you’re looking for desktop agnosticity, Personally, I don’t want to have to download an additional DE to use a WM in my current DE.
If you’ve got a Gnome desktop, you may very well be better off with the stability of compiz-proper if you don’t need bleeding edge. But if you’re running an alternate desktop, Beryl is worth looking at.
BTW, as a PSA there are packages built for Suse now on the build service now under http://repos.opensuse.org/X11:/XGL, these will replace the old compiz-quinn packages.
Edited 2006-10-01 01:41
Compiz is not tied to GNOME. Compiz is a CM and WM that isn’t tied to any specific desktop, because it was designed from the start to be that way. I can understand why David would be upset if people claim otherwise.
For example, here’s how I start compiz:
compiz –replace gconf&
gnome-window-decorator&
This means I’m specifically telling it to load the gconf plugin, and I have to start the GNOME-specific window decorator manually. You could develop a configuration plugin based on Qt/KDE (which would be much better than having a hack like csm), and of course you could also develop a new window decorator.
David Reveman mainly developed XGL and compiz. I think asking him to write the code for both GNOME and KDE window decorators and configuration plugins is a bit much.
Compiz is not tied to GNOME. Compiz is a CM and WM that isn’t tied to any specific desktop, because it was designed from the start to be that way. I can understand why David would be upset if people claim otherwise.
Try and compile compiz on a system without any Gnome libraries and then tell me it’s not tied to it.
This means I’m specifically telling it to load the gconf plugin, and I have to start the GNOME-specific window decorator manually.
And how do you configure those plugins?
And don’t get me started about the GNOME-specific window decorator.
You could develop a configuration plugin based on Qt/KDE (which would be much better than having a hack like csm), and of course you could also develop a new window decorator.
I could, but csm (now bsm) works fine, so why re-invent it which is what the beryl/compiz group has already done to accomodate existing deficencies? I’m not asking for KDE integration, I’m just asking for non-Gnome integration. I’ve got no problem with GTK-based apps since I already have the libraries etc. installed as part of my system. As for the window decorator, emerald (formerly cgwd, the community version of gwd) works great, so I’ve got no issues there either.
David Reveman mainly developed XGL and compiz. I think asking him to write the code for both GNOME and KDE window decorators and configuration plugins is a bit much.
Dave R. works for Novell, and since Novell’s existing customer base is still predominantly KDE-based despite their best efforts otherwise, I don’t actually think it’s expecting too much. But that’s a seperate argument, and not the point I’m getting at. Dave R. has no justification getting his nose out of joint when the community decides to expand his project from the specific base he originally targeted.
Again, don’t get me wrong. I’m not criticizing compiz, I’m merely criticizing Dave R.’s criticism of Beryl. Sure it’s a hack. But that’s basically what Stallman and Tanenbaum said about linux, as well. Never underestimate the power and determination of community, or presume to decide what’s better for them. That’s all.
Try and compile compiz on a system without any Gnome libraries and then tell me it’s not tied to it.
Perfectly doable, you’ll just miss out on the GNOME plugins and decorator, which are optional.
And how do you configure those plugins?
And don’t get me started about the GNOME-specific window decorator.
Ok, now I’m sure you don’t quite get how compiz works.
gconf support is a plugin. If you don’t build it, you won’t be able to configure compiz only if you don’t load an alternative plugin, which you could build and install against the original compiz codebase; no need to fork it to do that. If you write a decent plugin it will probably get merged into the official compiz tree.
As for the window decorator, it’s gtk specific. And it’s not part of compiz, you start a different process for the window decorator; compiz by itself won’t draw window decorations. You can build a window decorator externally, and use that. Again, if one builds a decent Qt/KDE window decorator I’m pretty sure David would merge it.
Dave R. has no justification getting his nose out of joint when the community decides to expand his project from the specific base he originally targeted.
Oh, please. He’s simply explaining that the reasons given by the beryl people to fork it are simply not correct. You can use a different window decorator and configuration plugin with the original compiz tree, because compiz was designed to allow that. Not to mention, complaining that a developer doesn’t hang around web forums is a bit pathetic.
Edited 2006-10-01 06:54
gconf support is a plugin. If you don’t build it, you won’t be able to configure compiz only if you don’t load an alternative plugin
Which is absolutely pointless. I’ve seen more than one system get hosed by gconf (it’s not the wisest thing to be using), and other open source projects that are desktop independent seem to have no trouble whatsoever creating a basic way of configuring their software through standard text files etc.
Why on Earth should anyone need a plugin just to configure it? There should be a means of configuring it simply, and then integrating it into specific desktop environments should people so wish.
It seems to me that the fork has come about due to elements of trust over the future of Compiz, rather than what you could actually do with it.
Which is absolutely pointless. I’ve seen more than one system get hosed by gconf
How so? GConf is not like the windows registry. You can delete it completely and everything will still run fine. I have yet to see GConf hose a system and I’m pretty interested in how you could possibely accomplish that.
Why on Earth should anyone need a plugin just to configure it? There should be a means of configuring it simply, and then integrating it into specific desktop environments should people so wish.
So it doesn’t depend on any DE or toolkit.
It seems to me that the fork has come about due to elements of trust over the future of Compiz, rather than what you could actually do with it.
It seems to me that the fork was made in haste without realizing the implications are current ability of compiz.
GConf is not like the windows registry.
No, it’s worse actually.
I have yet to see GConf hose a system and I’m pretty interested in how you could possibely accomplish that.
It’s based on XML and is a unified system. If any part of it becomes inconsistent, or corrupted in any way, the whole lot goes. I’ve seen it happen more than once with an update or some other calamity.
So it doesn’t depend on any DE or toolkit.
What on Earth are you talking about?
As it stands it depends on GConf for crying out loud, which is an utterly pointless way of configuring a piece of software that is supposed to be DE independent. Usually, such software can be configured with a simple configuration file somewhere in /etc. This is the normal way of configuring core software that you expect to just work.
It seems to me that the fork was made in haste without realizing the implications are current ability of compiz.
It seems to me that the Compiz people are asking people who simply want to run it to write their own configuration plugin if they’re not happy, which is utterly ludicrous. Imagine if you couldn’t configure Samba or Apache with a simple set of config files and you had to depend on a fairly unreliable system like GConf, or write your own if you weren’t happy.
> > GConf is not like the windows registry.
> No, it’s worse actually.
I’ve never experienced a problem with GConf, but I can attest that if you delete the GConf database, it will be regenerated to its default value.
It’s part of the design of GConf that it stores only user preferences and *not criticial functionality*, so its safe to wipe out.
That’s the key problem with the Windows Registry. It stores *everything* including OS settings and it stores it all over the place (rather than within a namespace). This means that if everything goes south, you can’t just delete your namespace and be done with it or delete the registry and have things return to “factory settings”. If the registry is corrupt, you’re SOL.
Do you really think GConf worse then the Windows Registry?
> > So it doesn’t depend on any DE or toolkit.
> What on Earth are you talking about? As it stands it
> depends on GConf for crying out loud,
Actually. From the comments given above, it doesn’t. Currently only a GConf plugin has been created, but you could just as easily define an .ini plugin.
> It seems to me that the Compiz people are asking
> people who simply want to run it to write their own
> configuration plugin if they’re not happy, which is
> utterly ludicrous.
You’d have to do this anyway if you create a fork, so how is this ludicrous?
The key thing I think is missing from compiz is simply the concept of a distribution. Currently, the compiz core ships with the “official compiz plugins”. If compiz were shipped a distribution and even provided space for alternate plugin distributions, then the whole Beryl issue would disappear. The Beryl distribution would ship with a platform independent configuration manager and experimental plugins. The Beryl-KDE would use a KDE specific configuraiton manager and a KDE decorator. Etc. It would be the best of all worlds.
I really don’t see a need to create a fork, but both sides have to *talk* and work out the ground rules.
That’s the key problem with the Windows Registry. It stores *everything* including OS settings and it stores it all over the place (rather than within a namespace).
Not a good idea for Compiz to be using something similar then.
Actually. From the comments given above, it doesn’t. Currently only a GConf plugin has been created
Which is the only way you can configure it currently.
but you could just as easily define an .ini plugin.
Since plain text files is what it should be using by default, with no plugins used, I find that funny.
You’d have to do this anyway if you create a fork, so how is this ludicrous?
Because there should be a base way of configuring it with no plugins being used.
The Beryl-KDE would use a KDE specific configuraiton manager and a KDE decorator. Etc. It would be the best of all worlds.
Integration with KDE would be useful, but using desktop configuration systems for something that isn’t a desktop application I still don’t agree with.
Dave R. has no justification getting his nose out of joint when the community decides to expand his project from the specific base he originally targeted.
Oh puh-leeze. David has every right to make intelligent and specific comments on a project he wrote 95% of.
If you read his comments you will see that he is concerned that the current changes in beryl (and by extraction most future changes) will be done in such a (hackish?) way to make them incompatible with upstream compiz.
Many of the plugins in beryl touch the core and are no longer implemented in a plugin type way. David offered an invitation for suggestions on how to improve the core APIs so that these beryl features could be implemented as plugins in a nicer way but no-one has stepped up and made said suggestions.
I guess its just easier to fork than it is to talk to a person these days…..
In essence beryl will be take take take and no give
That makes me sad
Dave R. works for Novell, and since Novell’s existing customer base is still predominantly KDE-based despite their best efforts otherwise,
…and your statistically accurate sources for this statement are?
…and your statistically accurate sources for this statement are?
Looking at the people who use openSUSE today, the most widely used Suse, you’d have to say that he’s correct. The vast majority of users still use KDE there.
I don’t see any sales and usage statistics that show that SLED is setting the world alight, which is what Compiz was designed for – a means for Novell to come up with a soundbite that said “Hey, look. We can do Vista style effects before Vista!”
I will support whatever is the most neutral tool. The one which isnt tied to one destop environment and just its libraries.
I for one love the new Beryl fork. On my system, it’s just as stable as Compiz, which I used first. And, it’s extremely easy to setup. Even though I use Gnome as my primary desktop, I don’t like it when tools unrelated to Gnome require Gnome’s goofy Gconf-editor, which reminds me of Windows registry. Furthermore, I like the fact that the Beryl community isn’t afraid to try new things and move forward with community input. So what if the code is a little rough around the edges right now. It works regardless. Don’t worry, it’ll be polished in time. In the meantime, choice is always good.
cgwd was not polished, jerky and leaked memory badly, i’m all for progression but they progressed with copying in mind. To me it was rushed just to get Vista-like theming and effects.
Gconf was a good way of storing configuration of compiz, it’s just configuration and not tied to the OS unlike Windows registry.
Edited 2006-10-01 03:42
… as I see it. Or what led to the things that happened.
Initially the means of communication and exchange for compiz-upstream were too much tuned towards the typical seasoned developer (only source-code, no real docs, only the mailing-list). I found it hard to get into working on compiz at the start. But I was interested and stuck with it. And it should not be forgotten that David had quite a large bunch of stuff to work on… glitz, Xgl, XRender, compiz, gwd. Nearly all of this he wrote single-handedly (sorry for the spelling). Also being at Novell he surely had the responsibility to take care Xgl & Co run well on SuSE. He was under much pressure I can imagine and not always able to respond more openly and frequently to the community.
For interested users (people that don’t live in cvs, git, autotools, gcc, make) who wanted to try Xgl/compiz on their machines such a setting was intimidating I can imagine. Enter the compiz.net-forum. There all sorts of people start gathering (technical people among them). People that can package stuff, write HowTos, start messing with the code, more plugins pop up. This forum quickly becomes almost like a web-log of “external” (from the compiz mailing-list) daily actions around Xgl/compiz. Web-forums just tend to have a lower entry-threshold than a mailing-list. Just look at the tons of people on any ubuntu-, Fedora-, Suse-forum compared to mailing lists. This kind of attraction of potential end-users makes it much easier to get a great exposure for your work you do on something like a compiz-plugin, when presented there. So somebody working on a new idea for a compiz-extension much faster and more immediately gets feedback and gratification for the work done via this communication-channel.
David promised to improve on this issue and already changed to a more open way of dealing with things. On the other hand side, the folks around beryl are also easy to along with around. I like to “hang around” both, the upstream mailing-list and beryl’s forum. I find it a bit unfortunate how things went.
Just my 2/100.
Best regards…
MacSlow
Perfectly doable, you’ll just miss out on the GNOME plugins and decorator, which are optional.
Yeah, let’s run Compiz with pretty cube effects and no window decorations. Yes it’s optional, but so’s the X server – it’s optional, but quite difficult to do a lot of things without it.
Again, if one builds a decent Qt/KDE window decorator I’m pretty sure David would merge it.
But that doesn’t actually solve the problem completely; you’re then tied to either GNOME or KDE. Whereas cgwd did solve it; it isn’t tied to any specific DE, which I find a much neater way of doing things. You can still make it look like gwd, but it works for everyone.
I’ve been really impressed by the way that the community has been able to extend compiz so quickly from Novell’s original code, especially compared to the fact that my major beef with the original compiz still hasn’t been addressed in their code: the GNOME dependencies.
Yeah, let’s run Compiz with pretty cube effects and no window decorations. Yes it’s optional, but so’s the X server – it’s optional, but quite difficult to do a lot of things without it.
The X server is a good example, because the Compiz core is like the X server. It is completely independent of GNOME or KDE. There is no reason to fork the X server to get independent of GNOME. I don’t see why this is so difficult to understand.
Whereas cgwd did solve it; it isn’t tied to any specific DE
Funny, and there I thought cgwd stood for custom-gnome-window-decorator… But that is still besides the point, if you want to have a platform-independent window decorator, you don’t need to fork Compiz for it.
The worst case that could happen is that Beryl will become incompatible to Compiz and thus many of the plugins for Beryl would not work with Compiz anymore. If that doesn’t happen, then no serious harm will be done. Let them go wild with Beryl and experiment freely, but don’t tell us that they are solving fundamental issues that Compiz fails to address. Because they don’t.
I am opposed to the fork.
When I hear people say that “the fork is good because the rwo goals are different” I bow my head in shame. David R wants the same things as Quinn, a rocking WM/DE.
Its sad that now the fork has “started” there is no going back (in the short term) – the projects will onlycontinue to diverge. Compiz has just gained a whole bunch of features (pane, multi-head architecture stuff, support for metacity themes) and David has started being more active on the mailing list. Quinn and co. bought this fork on too quickly, sucumbing to every request on the compiz.net forums, and adding poor quality code and hacks all over the show. I mean there has not even been an official compiz release yet!, why fork, how many years did it take to get a solid DE and people are impatient over compiz, a young project with no official release?
If Quinn and co. would have cooled their jets for another month or so then this for wouldnt have happened. If there is a difference in the projects goals it is that one (compiz) has a BDFL that has a grander vision and quality for the project, and that the other (beryl) doesnt. Its a free for all.
About the GNOME dependancies. Its only gconf. Quinn wrote a plugin to replace gconf (csm) but it was done in such a hackish way that it wasnt clean. I wish they would have just improved the csm plugin to the quality that it could be accepted upstream and then this whole fork rubbish could have been avoided.
End Rant
Why are people getting their panties in a buch over the forking of Compiz to Beryl? People are obviously polarized for different reasons. While some moan and groan over how hackish and rough the code in Beryl is, the fact of the matter is that most end users won’t know this as long as everything just works. If Beryl proves itself unstable and buggy, people will seek out Compiz. When Compiz incorporates enough of the hastily added features of Beryl then maybe more people will appreciate its more technical, polished and systematic development modus. In the meantime, visual bling and zing is all the rage on Linux desktops everywhere. God knows we in the Linux community have certainly waited long enough for accelerated desktops while our Mac friends gloated their pretty Quartz Extreme desktops for years. Choice is good. Let the users choose and may bhe best Linux bling win!
I don’t know anything about the issue other than what I’ve read on OSAlert, but from this uninformed viewpoint, two things seem evident (I’m sure someone will correct me if I’m wrong):
* Quinn’s patches were against the unstable branch, so of course they would be unstable. A separate fork will allow her patches to stabilize.
* If the patches stabilize, then Beryl could evolve into an incompatible fork since the Compiz and Beryl developers seem not to get along, and this incompatibility would hurt the advancement of XGL effects on the Linux desktop.
* Compiz and Beryl basically do the same thing, so even if the plugins remain compatible, all that’s being done by a fork is dividing the developer community and two talented developers.
* Compiz has a plugin architecture that should allow decorators and configurators to be made for other desktops, but no configurators or decorators yet exist for other desktops in Compiz.
* The Compiz maintainer does not like the design of the Beryl platform independent configurator and decorator, but this has left people who don’t use GNOME and don’t want to use GNOME libs the no option but to use Beryl.
From this uninformed view, it appears that the best solution is to make Compiz’s *releases* modular in much the same way as X.org is. Yes, I know that Compiz is modular, but a modular release would allow people to use the Compiz core with Beryl configurator and decorator, or its own, or the beta version of either (for the bleeding edgers who love glitz more than stability). This would allow Compiz and Beryl to co-exist grow stronger together, even as the developers work apart on different distributions of the same Compiz core.
Edited 2006-10-01 14:15
I believe designing this kind of software engine by just pushing quick hacks to CVS is going to turn the code into garbage very soon. But maybe popularity of the project will attract more skilled people who will then do it the right way. Pity that they decided to fork, as Reeveman is the driving force behind compiz (obviously a community doing this has a bit different short-term goals and many people aren’t as capable of doing the hard part).
Good side is, the project will certainly serve as a testbed for new ideas/plugins and I think this part of development is finally getting some momentum, and it probably wouldn’t start around “vanilla” compiz so easily.
Obviously you aren’t a software developer.
I have no idea how “hackish” the beryl code, but the evaluation of a code’s worth shouldn’t just be that it appears to work.
How many programs/OSes have had issues using this same kind of approach. A solid/proper foundation is ALWAYS the best method.
I have to wonder what distros are going to use beryl and which stick with compiz?
Seems KDE 4.0 will implement a composting manager in its window manager for KDE 4.0 and it will likely work based on the compiz tree.
Just look at any distro forum and you can see the confusion having the two separate branches has already caused.
“I have no idea how “hackish” the beryl code, but the evaluation of a code’s worth shouldn’t just be that it appears to work.”
Hmm. This has obviously worked well for Microsoft over the years. Windows still has better than 90% of the OS market and it is, by most accounts, some of the most hackish code in existence. Many people contend that Microsoft itself doesn’t even know what all is in those millions of lines of code. Yet, the fan boys here and on other forums talk about the upcoming Vista as if it were the second coming of Christ.
Like I said, the code is rough now, but give it time. This fork has been in existence for how long? A week? Maybe two? Good grief man!
You miss the point. Microsoft has add many problems and issues over the years trying to build onto flawed base parts. Go read microsoft journals of its own developers.
Microsoft’s market share has very little to do with the quality of the OS.
The X server is a good example, because the Compiz core is like the X server. It is completely independent of GNOME or KDE. There is no reason to fork the X server to get independent of GNOME. I don’t see why this is so difficult to understand.
The compiz *core* is, yes, but there is only one window decorator shipped with vanilla Compiz, and it depends on GNOME. I think it’s fair to say that most people would *not* consider a WM with no decorations to be adequate to their needs.
Funny, and there I thought cgwd stood for custom-gnome-window-decorator… But that is still besides the point, if you want to have a platform-independent window decorator, you don’t need to fork Compiz for it.
It doesn’t, it stands for custom-generic-window-decorator – GNOME would make no sense since it has no connection to it.
You’re probably right that they didn’t need to fork Compiz just for that – I don’t claim to know the technical reasons behind that. I’m simply saying that compiz-quinnstorm achieved a lot that vanilla compiz didn’t, such as providing a non-GNOME-dependant decorator, and their own configuration system so gconf wasn’t necessary.
I won’t say whether the latter was a good thing or not, but they obviously felt it necessary. Either way, it shows that they’ve put a considerable amount of time and effort into their branch of compiz, they’re not just forking it for kicks.
Let them go wild with Beryl and experiment freely, but don’t tell us that they are solving fundamental issues that Compiz fails to address. Because they don’t.
Yes, they do! I can run compiz-quinnstorm/Beryl (call it what you will, they’re essentially the same at this point) on my machines and have window decorations without installing 20 GNOME packages. That is not possible in vanilla Compiz. Whether you like it or not, that is a big problem that they have solved.
The whole thing strikes me as being a bit similar to gcc and egcs; egcs split off to do their own thing, but eventually it all came back to the fold (as far as I can remember anyway; Wikipedia isn’t replying to me to confirm my recollection). Maybe this will end similarly.
So you think that instead developping Gnome-independent window decorator as compiz plugin wiser step is fork project? Doh!
So you think that instead developping Gnome-independent window decorator as compiz plugin wiser step is fork project? Doh!
No, I didn’t say that.
I’m not aware of the technical side of the situation; it may be that they couldn’t implement cgwd in compiz as it stood; I don’t know. I’m just saying that compiz-quinnstorm made significant progress as a seperate branch, in areas that compiz didn’t, and personally I’m happy that progress has been made since it’s scratched my itch. I’m not so concerned about how the project is developed as what has been developed.
I think there are good and bad forks, and you can quantify the forks in a number of dimensions.
egcs for instance was a gcc fork that became *the* gcc once it was determined that it was the best way of moving forward. Some other forks like Xemacs and Emacs had to do with release time frames, but the license was kept compatible so code could be shared between them.
In my opinion, the Compiz/Beryl fork is a bad fork on two grounds: Compiz is maintained with “git” which would have allowed the Beryl folks to keep and maintain their own tree had they wanted to just get the new features in. But instead they imported the code into Subversion losing the development history and making it harder for anyone to cherry-pick features.
Then there is the license change from the dual X11/GPL to only GPLv2, which prevents code in Beryl from flowing back into Compiz.
The change of license, and the change of repository and quickly jumping the gun on the fork (barely a weekend had passed since their initial post, and David’s reply) that in my opinion, this fork is not based on technical merits but on other reasons.
As the Beryl folks have yet to give a credible technical reason on any of those areas (change of repository, relayout the code, change the license, need to fork over “plugins” (???)) I can only guess what the real reasons are, but my guess is as good as anyone else’s, all I know for sure is that this was not a technically needed fork.
Hello,
One thing that folks might be missing is that the configuration for compiz comes from a “backend”. In the particular command line invocation shown in the various other posts, compiz is invoked like this:
compiz gconf or compiz –replace gconf
What this command line says is “load the plugin gconf”, you can list as many plugins as you want on the command line, and compiz will load libXXXXX.so and execute it. In this particular case it loads the libgconf.so plugin which happens to load the configuration from gconf and load any other plugins listed there.
There is nothing stopping anyone from writing a new plugin, based on .txt files, .ini files, d-bus, dcop, or whatever other configuration system you want and invoke it with:
compiz –replace my_config_system_is_better_than_yours
All of this (as pointed in David’s email) can be achieved with the current plugin architecture.
Dave and the Novell gang are changing their tune becuase they know that Beryl is going to steal Compiz’s thunder. If you hang around Compiz.net, it would already be clear that most users and developers used Quinns tree anyway. The packagers always made the vanilla compiz availible, but Quinns branch was always the most discussed and active branch. It’s funny that people want to all of a sudden talk about code quality when most people couldn’t read a line of code if their life depended on it. Beryl might be experinceing a little instability whyle totally seperating from Compiz, but it has been rock solid for the most part. Sure, you’re going to hear someone say it dopesn’t work on my PC, but just spend a week or so on Compiz.net and see if code quality is an issue.Compiz is heading the way of the old X window manager before xorg, and the Novel group know it. Sure, their going to continue to develope it, but you have to remember that many in the community have never been fond of Novels behind the curtain communications and development practices. The fork is cool, because the community developers are already firmly behind Beryl, and the corporation is frimly behind Compiz.
Dave and the Novell gang are changing their tune becuase they know that Beryl is going to steal Compiz’s thunder. If you hang around Compiz.net, it would already be clear that most users and developers used Quinns tree anyway. The packagers always made the vanilla compiz availible, but Quinns branch was always the most discussed and active branch. It’s funny that people want to all of a sudden talk about code quality when most people couldn’t read a line of code if their life depended on it. Beryl might be experinceing a little instability whyle totally seperating from Compiz, but it has been rock solid for the most part. Sure, you’re going to hear someone say it dopesn’t work on my PC, but just spend a week or so on Compiz.net and see if code quality is an issue.Compiz is heading the way of the old X window manager before xorg, and the Novel group know it. Sure, their going to continue to develope it, but you have to remember that many in the community have never been fond of Novels behind the curtain communications and development practices. The fork is cool, because the community developers are already firmly behind Beryl, and the corporation is frimly behind Compiz.
I’m personally waiting for KDE 4, right now I’m using KDE 3.5 and is very nice, I was using GNOME 2.14, I havn’t tried 2.16 yet, but I’m staying with KDE 3.5, is more configurable and more pleacent to use. KDE 4 will use Plasma and we will not need Compiz/Beryl, it will have it’s own compositing manager, GNOME already has one but is pretty limited in effects I think, I’m sure Plasma will have a lot and really nice eye candy.