Linked by Thom Holwerda on Sat 17th Feb 2007 18:45 UTC, submitted by GhePeU
X11, Window Managers David Reveman writes: "I'd like to get all of you updated on the compiz related things discussed at the X developer conference that was held last week. My talk was mainly focused on 'what's next' and how to get desktop compositing in X to the next level." He also discussed the fork: "I had the chance to talk to Quinn Storm from the beryl project during xdevconf. I would have hoped that the current situation with beryl could be improved but it seems like Quinn at least isn't interested in that. However, after talking to Quinn it's very clear to me that the fork was partially motivated by assumptions that were wrong."
Thread beginning with comment 213964
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: sour grapes?
by apoclypse on Sat 17th Feb 2007 23:49 UTC in reply to "RE[2]: sour grapes?"
Member since:

Exactly. Beryl doesn't deal with the internal of x the way compiz does, because frankly the beryl devs don't know how, that much is obvious by beryl itself. The fact is if things are done correctly from the get go, they wouldn't have reimplement things correctly later. Chances are when things do get implemented correctly its not going to be code coming from the beryl devs instead they are going to be using code from compiz, getting all the benefits and giving very little back to the project that started the whole thing to begin with. What the beryl devs have done is pander to every fool out there who wants eyecandy, implement a hack to get it working, giving the user a perceived "better than compiz" impression because compiz won't pander to every idiot request being put out there. The fact is beryl got forked because of the hacks that were being put into it. Dave has always maintained that everything should be implemented through plugins and if can't be done with plugins THEN update the core. Beryl took a different approach and instead was patching the core left and right for something that shouldn't be done there in the first place. The biggest example is the BSM, the beryl devs claimed that compiz relied to much on Gnome, when in-fact this wasn't true at all, compiz was made to have any backend implemented through plugins. The beryl devs took it upon themselves to implemented an extremely hackish settings manager that btw still relies on gtk. Guess what when they wanted to be considered to be the default Wm in ubuntu (composite by default spec) they had written themselves into a corner and had to rewrite it.

Edited 2007-02-17 23:54

Reply Parent Score: 5

RE[4]: sour grapes?
by segedunum on Sun 18th Feb 2007 23:20 in reply to "RE[3]: sour grapes?"
segedunum Member since:

The biggest example is the BSM, the beryl devs claimed that compiz relied to much on Gnome, when in-fact this wasn't true at all

When, for no apparent reason whatsoever, the only current working way of getting configuration settings was through GConf, and David Reveman's standard answer was "Oh you can write a separate plugin" I don't really see a need for that, nor does it inspire confidence in its future.

The beryl devs took it upon themselves to implemented an extremely hackish settings manager that btw still relies on gtk.

Well no actually. Beryl uses a flat file method for storing configuration settings, which is the way things should be, and then the Beryl Settings Manager (GTK) or a KDE version can be implemented on top of here - like just about everything else. There is no reason for anyone to write a separate plugin to store config settings for a piece of software that is fundamental to a desktop. It's more work for absolutely nothing, and means more things to go wrong.

Seriously, people demanding reasons for the fork is just pointless.

Additionally, people are forgetting the history of Compiz. The Beryl people have argued that a fork was necessary because they just couldn't trust David Reveman and Novell to be open about it (not that they don't respect him), and because of the undocumented method of the code itself. Given that Compiz was developed in a closed environment for some time until someone asked about it, and Novell then perked up and said "Oh, oh, oh, we were going to release that in February anyway", it just doesn't inspire confidence. David and Novell simply made a bad decision there, and they'll have to take that on the chin.

Another thing levelled at Beryl by David is that they are somehow less skilled than he is, and as a result, things are hacked together. Quite frankly I don't care if he thinks that. The Compiz code isn't exactly the best organised in the world, nor is it partularly stable and great. If it was, people would be using Compiz en masse. The Beryl developers are learning about writing some software that they do not have huge expertise in, but they're committed and working hard at it and they're learning - which is what open source development is about really.

I'd rather have skilled people constantly learning, and making at least some mistakes, than someone who criticises what he thinks are temporary solutions and hacks.

Cut them some slack. If it work it works. If it doesn't then people may or may not flock to Compiz in the way David Reveman so obviously and desperately wants.

Reply Parent Score: 1