"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."
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2005-07-09
> > 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.
Member since:2005-07-06
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.
Member since:
2005-07-06
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.