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 213934
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: sour grapes?
by g2devi on Sat 17th Feb 2007 22:03 UTC in reply to "sour grapes?"
g2devi
Member since:
2005-07-09

It does sound that way. Some of the things he says makes sense (e.g. keeping the MIT license so as to allow code to be moved into X.org), but it does seem that he is out of touch with Beryl and just plain FUDful (e.g. willing to accept code without too many questions and references to kludge after kludge). There's also mention that Beryl continues to use Compiz code and doesn't give back, but no mention that Beryl plugins have been ported into compiz-extra by Compiz developers (at least according to Wikipedia:
http://en.wikipedia.org/wiki/Beryl_%28window_manager%29
)

Here's a view from the other side of the fence:
http://dev.beryl-project.org/~kristian/beryl/7/the-future-of-beryl/

You don't have to look too far to find it. It's directly on the main Beryl page in the "Planet" section.

Given the Beryl link and the Compiz link, my uninformed impression is that the real reason for the fork is something glossed on by both sides:

1) the Compiz team what's their code to get into X.org and so they try to make it compatible with the X.org low level code.

2) low level X.org code is overly complicated out because of it's generality and the Beryl developers don't see the reason for the complexity if all you want to have is a window manager. That complexity makes it harder for new people to join Beryl so they want to spend a lot of time refactoring the code to make it easier for new people to contribute. The Beryl team also found other places that limited contribution and started working on reducing those.

The result? More people contribute to Beryl that would have with Compiz, and some plugins have been ported back to Compiz giving more plugins than would otherwise be the place, and finally some compiz work has (or will) get into X.org which in turn allow Beryl to become better.

My own prediction is that Compiz will eventually disappear since the Compiz team's dream seems to be moving it's code into X.org. This in turn will give Metacity and KWin the ability to catch up to Beryl in most aspected except for support for multiple decorators and multiple configuration managers.

Reply Parent Score: 5

RE[2]: sour grapes?
by GhePeU on Sat 17th Feb 2007 22:39 in reply to "RE: sour grapes?"
GhePeU Member since:
2005-07-06

1) the Compiz team what's their code to get into X.org and so they try to make it compatible with the X.org low level code.

2) low level X.org code is overly complicated out because of it's generality and the Beryl developers don't see the reason for the complexity if all you want to have is a window manager. That complexity makes it harder for new people to join Beryl so they want to spend a lot of time refactoring the code to make it easier for new people to contribute. The Beryl team also found other places that limited contribution and started working on reducing those.


Oh, please, compiz/beryl need GLX_EXT_texture_from_pixmap, the composite extension, AIGLX, and where do you think all these things live? In the X.org code and in the DRI/nvidia driver code! there was no way to implement the 3d effects without those things. Then, when those thing were implemented in the proper xserver you could have those nice 3d effects. The input redirection is the same, to have more advanced effects you just need the infrastructure in the X server. Or you can use a ugly hack, and we all know that ugly hacks are evil.

On the compiz/beryl fork: David Reveman pretty much single-handedly wrote XGL and the first composite manager with 3d effects, and helped to define all the necessary specifics. If I have to choose, I trust him, not the beryl developers, who regularly "sync" to put in beryl the new compiz features and code without publicly acknowledging it.

Reply Parent Score: 5

RE[3]: sour grapes?
by apoclypse on Sat 17th Feb 2007 23:49 in reply to "RE[2]: sour grapes?"
apoclypse Member since:
2007-02-17

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[3]: sour grapes?
by Tweek on Sun 18th Feb 2007 17:49 in reply to "RE[2]: sour grapes?"
Tweek Member since:
2006-01-12

what is wrong with those syncs?

i dont beleive the licenses require them to acknowledge that they do it...

Reply Parent Score: 1