David's post linked

[imnotpc]

It looks like OS News linked David's post on the mailing list.

http://www.osnews.com/story.php/17296/Compiz-Update-on-xdevconf07-Beryl-Situation/

[FunkyM]

Actually it even made a DIGG ;)

http://digg.com/linux_unix/David_developer_and_maintainer_of_compiz_speaks_ab out_beryl

[nesnomis]

Ted Haeger, the speaker on Novell open audio has a nice article on his blog about this to... :) ...

http://reverendted.wordpress.com/2007/02/18/desktop-effects-updates/

[PaK]

WOW, disscussion on digg is more interesting that that on osnews. Too bad for osnews :(

[imnotpc]

How 'bout that. A little teaser for the compiz fans out there. You haven't heard a lot from me lately. There's a good reason...

[RYX]

I should stop reading such discussion - it drives me mad to see how silly some people are ... :)

[PaK]

RYX stop be angry geek! its bad for as all ;) :D

[PaK]

Some conclusion from all disscussions.

Beryl is so great that it is used in "many distributions".
David is upset to community that none is using compiz.
We are band of angry geeks.

In short Yet Another FLOSS Holy WAR!

[RYX]

RYX stop be angry geek! its bad for as all
Yes, I know ... That's why I didn't comment on any of those discussions ... :)

It's good that David's post gets big attention. Information is the only way to make people understand ...

[PaK]

Indeed but there is black side of moon, for example kirstian didnt answered at any comment on hist blog about "how david code is bad". As in democracy, "so what if you are intelligent person who can vote ? if 10 idiots can vote too and they have the same vote as you ?" Even if beryl users are spreading FUD and dont really know what they are talking about, they will do a lot damage even if compiz users, developers will defend compiz using technical arguments. I dont say every beryl users is evil, i just want to say how much damage will do 1 FUD spreader for whole community. This is the worst side of open source ;( i see this behavior from the beginning of my open source concern

[PaK]

http://lists.lri.fr/pipermail/metisse/2007-January/000163.html

[mikedee]

http://lists.lri.fr/pipermail/metisse/2007-January/000163.html

Looks like quinn is looking for another project that they can leech off. It is sad.

I suppose we will be seeing a fork of metisse soon...

[RYX]

Now that Quinn has been "branded" on xdevconf - she/he is looking for a not so popular project to steal from ... I am looking forward to see "beryl-facades", "beryl's rotating windows", ... only to see them move even further away from their goals and roadmap and finally move entirely towards total chaos ...

There is a german saying: "Too many cooks ruin the meal" (which I think I translated very bad) ... their windows already burnt :D ...

:)

[maniac]

Now that Quinn has been "branded" on xdevconf - she/he is looking for a not so popular project to steal from ... I am looking forward to see "beryl-facades", "beryl's rotating windows", ... only to see them move even further away from their goals and roadmap and finally move entirely towards total chaos ...

Can you please try to see that Beryl != Quinn? Quinn is one of the developers, but not the most active one or even the only one. As there are a number of developers, there also are a number of opinions - and guess, some of the opinions even see that cooperation would make sense (I'm of this opinion, BTW). But obviously FUD spreading, trash talking and flaming don't help at help with this.


There is a german saying: "Too many cooks ruin the meal" (which I think I translated very bad) ... their windows already burnt :D ...

This saying does not match at all with what you said before...in your first sentence you make it look like Quinn IS Beryl and then you come up with "Zuviele Köche verderben den Brei"? You must be kidding :shock:

[RYX]

Forgive my ranting but I (still) disagree with the reasons and motivations behind the beryl-project - which does not mean that I dislike any of the developers or the users (instead I like most of them) - and a little ranting here and there is the only way to reduce my anger and frustration about this ongoing waste of effort ... The end-user is the real loser of all that. Everyone knows that beryl has no valid reason to exist as separate application ... except the personal benefit for a handful of people.

I definetly not think that Quinn=beryl but it is often said that he/she is the "leader" of the project and he/she seems to be the spokesperson as well. How and if that is true is beyond my knowledge ...

"Zuviele Köche verderben den Brei" because one could get the impression that beryl has too many people who think they are in the lead ... and all of them seem to be heading in different directions ... (but I don't know enough about beryl-internals to know if that is really true and, honestly, I don't care either). I, personally, prefer the situation in compiz ...

And as you may have noticed - this is "Compiz Talk" ... so don't expect me to be neutral here.

:)

[mikedee]

Now that Quinn has been "branded" on xdevconf - she/he is looking for a not so popular project to steal from ... I am looking forward to see "beryl-facades", "beryl's rotating windows", ... only to see them move even further away from their goals and roadmap and finally move entirely towards total chaos ...

Can you please try to see that Beryl != Quinn? Quinn is one of the developers, but not the most active one or even the only one. As there are a number of developers, there also are a number of opinions - and guess, some of the opinions even see that cooperation would make sense (I'm of this opinion, BTW). But obviously FUD spreading, trash talking and flaming don't help at help with this.

I would not let your leader hear you saying that she is just a developer and not the most active one. She might lose your plugins in some sort of hard drive crash :D

RYX's comments are correct, your leader has been branded and Kristian is setting himself up for the same thing. I would be embarassed to give the sort of demo Quinn gave to the people at XDev.

In case you are confused at who is who and who's ass you should be kissing, look here.

http://www.beryl-project.org/team.php

"Zuviele Köche verderben den Brei"?

It translates perfectly to English and in fact sums up your problems at the moment (too many people all wanting to do their thing with beryl, no leadership or direction)

[imnotpc]

Can we please have a discussion without taking shots at beryl/Quinn. Maniac, delfick, and others are our guests here and it seems every thread lately ends up with trash talk about beryl. We all want the beryl community to "come home" yet our community leaders are making it real unpleasant for anyone affiliated with beryl to be here. Seems counterproductive to me (not to mention unfriendly).

[maniac]

Can we please have a discussion without taking shots at beryl/Quinn. Maniac, delfick, and others are our guests here and it seems every thread lately ends up with trash talk about beryl. We all want the beryl community to "come home" yet our community leaders are making it real unpleasant for anyone affiliated with beryl to be here. Seems counterproductive to me (not to mention unfriendly).

Thank you.
To make it clear: I in no way have any problems with rational arguments pro Compiz / contra Beryl; but I have problems with personal attacks. Nice to see that you share this opinion :)

Forgive my ranting but I (still) disagree with the reasons and motivations behind the beryl-project - which does not mean that I dislike any of the developers or the users (instead I like most of them) - and a little ranting here and there is the only way to reduce my anger and frustration about this ongoing waste of effort ...

Well, I disagree. Ranting/Flaming easily can be taken personal depending on how it's expressed. To be honest, I often felt attacked personally without being responsible for the fork and without attacking someone personal from my side. So I read your statement as kind of apology - which is nice :)
I also have to disagree about the fork reasons...well, at least partly. With David's development model I never would have become a Compiz developer. When I started Beryl coding, I was a starter at GL and Xlib after all, as I before mainly developed for Win32. I have learned a lot through all that, and I think that I have fixed more than I have damaged ;)
I'm not sure if there's a better development model right now as long as David is as strict on so-called "hacks" or "workarounds" as he is now. Please note, I'm not talking about sloppy programming in general. I'm talking about things like offscreen windows and minimized window pixmaps, which are just necessary to make certain things work until there is input redirection. And yes, we really appreciate David's work on this - at least I weren't able to do that.
At the end, it's all a give and take. Beryl takes Compiz' core improvements; while Compiz takes Beryl's plugin improvements. The only thing lacking is an official Compiz repository for the ported Beryl plugins. ;)
Of course it would make more sense to have one repository for everything - but as there are certain requirements from both sides, we'll have to see what time will bring.


Well, I
I definetly not think that Quinn=beryl but it is often said that he/she is the "leader" of the project and he/she seems to be the spokesperson as well. How and if that is true is beyond my knowledge ...

Well, yes, Quinn is the official leader of the Beryl project. However, the official spokesperson is DBO (Jason Smith) as you can see from the Public Relations part of the team page.


"Zuviele Köche verderben den Brei" because one could get the impression that beryl has too many people who think they are in the lead ... and all of them seem to be heading in different directions ... (but I don't know enough about beryl-internals to know if that is really true and, honestly, I don't care either). I, personally, prefer the situation in compiz

Of course it's easier if there is only one person in charge as David is for Compiz. This significantly reduces the amount of noise, but also reduces the amount of ideas ;)
But generally speaking, people expressing their ideas loud shouldn't automatically be taken as the leaders or as people applying for leadership.


And as you may have noticed - this is "Compiz Talk" ... so don't expect me to be neutral here.

Heh, no problems with that, as long as the arguments are rational and not emotional :)

[mikedee]

I also have to disagree about the fork reasons...well, at least partly. With David's development model I never would have become a Compiz developer.

I think this is another mistruth that has been spread about Compiz and David. You do not have to agree with him at all to develop plugins. You can develop plugins however you feel.

If you want to work on the core then I am afraid that you do need to live by his rules. I think most of us agree that we want a stable fast core and he is just defending that.

As his recent post highlights though, he does understand that some hacks are necessary and he is not against a hacky BRANCH. I even think he agreed with the original compiz-quinn branch. The problem is that no patches went back because of (IMHO) poor management (not by you, please dont take that personally :))

When I started Beryl coding, I was a starter at GL and Xlib after all, as I before mainly developed for Win32. I have learned a lot through all that, and I think that I have fixed more than I have damaged ;)

If this is the case, then can I ask (without flaming) why you do not send fixes 'upstream'?, personally I am in a very similar position and I decided that the fork was wrong and that if I was going to do any patches I would send them to Compiz and not beryl. These are the reasons (again don't flame them, its just my view of things).

1. I can get the seal of approval when I do things right, and learn when I do things wrong. There are lots of hacks in beryl which I know for sure are just because they didn't understand something properly.
2. Beryl will take any code I put into Compiz anyway, so effectively I get to contribute to 2 projects for the price of 1.
3. I can be sure that I can go to the right person for a definitive answer as to WHY a function does something (not what it does).
4. I have a moral obligation to the person that spent years developing the software, I do not think the fork was valid or friendly. I think that even though Compiz lacks some features now, it will be much better than beryl very soon. The problem is there was no feedback from plugin developers as to what was needed. I think this is changing now.
5. I can see the future for beryl and its not good I am afraid. You see, those of us who have been programming for a while know the beryl development model all too well, we know where it leads. I do not mean this is a bad way, we wish it would work, but it doesn't.

As for hacks, please see the mailing list. I would not be surprised to see a compiz-hacks branch soon. The difference is that every hack will be atomic and documented. We will aim to get the hack fixed by whoever needs to fix it, then remove it. The aim will be to not have any hacks.

Once the hacks are fixed by the toolkit or application developers then beryl will be in a sticky situation because it will be hard to identify the hacks and cleanly remove them. They have not done anyone any favours by not identifying and reporting these fixes to anyone.

[stalynx]

With David's development model I never would have become a Compiz developer. When I started Beryl coding, I was a starter at GL and Xlib after all, as I before mainly developed for Win32. I have learned a lot through all that, and I think that I have fixed more than I have damaged ;)

I've never seen DavidR reject an implementation on the basis of code. Rather if the implementation is sound in the design sense but the code is not entirely correct he will either fix it himself or tell the submitter how to fix it.

Even DavidR has his code thoroughly checked. See his client side software cursor on the xorg mailing list. The difference is he defends his arguments, makes concessions and fixes errors. He doesn't fork xorg.

[maniac]

I also have to disagree about the fork reasons...well, at least partly. With David's development model I never would have become a Compiz developer.

I think this is another mistruth that has been spread about Compiz and David. You do not have to agree with him at all to develop plugins. You can develop plugins however you feel.

If you want to work on the core then I am afraid that you do need to live by his rules. I think most of us agree that we want a stable fast core and he is just defending that.

Well, yes and no. Yes, I don't need his approval to work on plugins. But no, there is no common repository where 3rd party plugin developers can store their code. As bug fixing is much easier for beginners than writing a complete new plugin, that's a hurdle for starters.


As his recent post highlights though, he does understand that some hacks are necessary and he is not against a hacky BRANCH. I even think he agreed with the original compiz-quinn branch. The problem is that no patches went back because of (IMHO) poor management (not by you, please dont take that personally :))

To be honest, I don't like the term "hacky" in the context you use it. There are a lot of things which work around limitations in the X system, but as they are cleanly implemented (I'm talking about the above mentioned offscreen windows and minimized window pixmaps), I think the term "hack" is not appropriate for them. "Workaround" suits it best IMO ;)


When I started Beryl coding, I was a starter at GL and Xlib after all, as I before mainly developed for Win32. I have learned a lot through all that, and I think that I have fixed more than I have damaged ;)

If this is the case, then can I ask (without flaming) why you do not send fixes 'upstream'?, personally I am in a very similar position and I decided that the fork was wrong and that if I was going to do any patches I would send them to Compiz and not beryl. These are the reasons (again don't flame them, its just my view of things).

Just one word: Convenience. Yeah, you can call me lazy or anything, but that's how it is. I use Beryl personally because it's more convenient for me (I prefer BSM over gconf-editor, which may be a matter of taste, and prefer not having to use a separate utility when I want to get my windows blurred ;) ). Additionally, Beryl provides a nice repository to glue all things together. You have to admit that this is more appealing to developers than sending around patches and having to unpack tarballs and make each of them separately ;)



1. I can get the seal of approval when I do things right, and learn when I do things wrong. There are lots of hacks in beryl which I know for sure are just because they didn't understand something properly.

Yes and no again. Yes, you are right, getting a pointer on how to get it done properly is nice. However, David in the past sometimes (not always, I know) has been quite rude (remember that kwd announcement? Why didn't he work together with onestone?) and sometimes patches are sent to the ML, but don't get applied (such as the place patch lately). Certainly not a nice situation for a developer.


2. Beryl will take any code I put into Compiz anyway, so effectively I get to contribute to 2 projects for the price of 1.

See me convenience argument above ;)


3. I can be sure that I can go to the right person for a definitive answer as to WHY a function does something (not what it does).

Basically the same as 1.


4. I have a moral obligation to the person that spent years developing the software, I do not think the fork was valid or friendly. I think that even though Compiz lacks some features now, it will be much better than beryl very soon. The problem is there was no feedback from plugin developers as to what was needed. I think this is changing now.

Hmm, why is there no Beryl-ported-plugin repository? In fact, at least I even encourage people to port Beryl plugins (I pointed Amaranth to the latest wall changes just an hour ago), so why is there no repo to get rid of the unpack-tarball-and-make-pain for the users? This way, IMO everything would work fine: Compiz users get the plugins, Beryl users get the core. Beryl would be more experimental in nature, Compiz more stable.
The problem with Compiz right now is that it is in the state of a technology preview. Please don't get me wrong, I do not say that Compiz is bad or anything. It's just that it lacks things like a configuration editor that grows with the plugin options (such as BSM, one may argue about the option layout...) which prevent Compiz from working out-of-the-box. Again, I share your opinion that it would be a wise idea to create those things together. But (as already pointed out) that's not that easy as both sides have their requirements.


5. I can see the future for beryl and its not good I am afraid. You see, those of us who have been programming for a while know the beryl development model all too well, we know where it leads. I do not mean this is a bad way, we wish it would work, but it doesn't.

On the other hand, if an OSS project can't recruit developers working on it, it has a problem, too ;)


As for hacks, please see the mailing list. I would not be surprised to see a compiz-hacks branch soon. The difference is that every hack will be atomic and documented. We will aim to get the hack fixed by whoever needs to fix it, then remove it. The aim will be to not have any hacks.

Sounds almost good. But architectural changes in core would have to be merged back to the branch anyway, right? And where's the discussion about what "hacks" (workarounds) to include? ;)


Once the hacks are fixed by the toolkit or application developers then beryl will be in a sticky situation because it will be hard to identify the hacks and cleanly remove them. They have not done anyone any favours by not identifying and reporting these fixes to anyone.
This sentence confuses me, sorry. Can you please rephrase it? :oops:

[PaK]

The problem with Compiz right now is that it is in the state of a technology preview.

Well Beryl is technology preview too, the main reason is probably that compiz and beryl are not 1.0 version ?

And i thnik argument that you show about that technology preview of compiz isn't a real argumet, compiz works out of box even without gconf.

[imnotpc]

Additionally, Beryl provides a nice repository to glue all things together. You have to admit that this is more appealing to developers than sending around patches and having to unpack tarballs and make each of them separately
You have a good point about the repository issue. Unfortunately we've had to build a site from scratch and this feature is still incomplete. We're working on it.

[mikedee]

remember that kwd announcement? Why didn't he work together with onestone?

I'd just like to quickly pick you up on this specific point. If you are looking for people who are cooperating and people who are being rude you should look a little earlier in the mailing list when onestone originally presented aquamarine to David.

David was very cooperative and tried to work with him, but his suggestions were just brushed off with an attitude like 'well it works in beryl - so you work it out and send me patches'. Onestone was not cooperative or receptive to constructive criticism.

Personally I do not think that the KWD release announcement was rude at all, to me it seemed a factual explanation of what he has done and the reasons for it.

Yes David can be straight to the point sometimes, I think thats just how he is (many developers are), don't take things too personally.

[iznogood]

one more time we are at a lose - lose situation here....

if beryl is an experimental branch of compiz then what are they doing at xdevconf??? they did not show anything new...I am amazed that quinn did something like that. It clearly shows that the man only cares about how he becomes known around the community, otherwise why spend time on something like that when you know that people will laugh in your face with what you will show them??? People there where experts not just users and could not be fooled by few visual effects.

Anyway the point is that we spend resources for nothing and i believe that its only pride that stops at least a few beryl people to join us here, otherwise why bother answer our posts here?? This whole big issue began just because a few people did not want to have their code checked by others, because they though that what compiz was a few months ago was all that it will ever be (core wise) but as we see things are diverting very much away from this.

The only thing we miss is a central repository (outside xorg) to experiment with new things and then submit them for formal inclusion in compiz or compiz-extra, thats it.

Now if people want to duplicate - fork code for educational purposes this is great but this does not make it a full project to replace compiz or any part of it. How many decorators are there?? I would have preferred if all these features like pulsing buttons and transparency where submitted to the existing decorators (even on gnome or kde) and not reimplementing them.

The way things are going i do not see anything good coming out of this.I do not see many new plugins on beryl and it seems that they understand that visual effects are not the most important thing anymore but they do not know how to move forward.

Guys why don't you leave the expert to show the way??
Very soon he will have a lot of time to spend with plugins devs to help out and implement your suggestions either to the core or anywhere he thinks its best. I do not see why go on with this. If Quinn, Xice, kristian or anyone else want to continue with the fork, let them but do not let this opportunity go wasted.

[RYX]

On the other hand, if an OSS project can't recruit developers working on it, it has a problem, too
I'd rather say that if an OSS-project needs to "recruit" developers at all there is some sort of problem. I guess I speak for all the compiz-devs and -users when I say that we stick with compiz because we want to, not because someone recruited us ... ;)

The reason that beryl has more users and devs is that they (the beryl-officials) forced the whole compiz-community into a new project and a new name without making a single poll about it (I am a witness - it has all been decided outside the communities' visibility). I don't want to bring up any fork-discussion here but beryl has been undemocratic and selfish from the very first minute of its existence - that's a fact.

If people like working for a project that is built upon such immoral ideas and events - it's up to them ... I couldn't.

(Again - no personal offense against anyone ... only my personal opinion)

:)

[maniac]

remember that kwd announcement? Why didn't he work together with onestone?

I'd just like to quickly pick you up on this specific point. If you are looking for people who are cooperating and people who are being rude you should look a little earlier in the mailing list when onestone originally presented aquamarine to David.

David was very cooperative and tried to work with him, but his suggestions were just brushed off with an attitude like 'well it works in beryl - so you work it out and send me patches'. Onestone was not cooperative or receptive to constructive criticism.

Hmm, some of his comments were indeed a bit ... err ... bugged (if anyone has a better translation for the German "genervt", let me know ;) ); while others were quite firendly asking for help.

Personally I do not think that the KWD release announcement was rude at all, to me it seemed a factual explanation of what he has done and the reasons for it.

Well, the mileage may vary, but wording like "ugly hack" sounds rude to me at least.


Well Beryl is technology preview too, the main reason is probably that compiz and beryl are not 1.0 version ?

That's not my point, and I think you are aware of that.

And i thnik argument that you show about that technology preview of compiz isn't a real argumet, compiz works out of box even without gconf.

Yes, technically it works, but I wouldn't consider that state usable. Things like keybindings and number of viewports, which really are personal preference, couldn't be adjusted at all...would you really use such a program? IMO, one should never underestimate the need for a decent settings manager if it isn't built into the DE like it is for Metacity and KWin.


f beryl is an experimental branch of compiz then what are they doing at xdevconf??? they did not show anything new...I am amazed that quinn did something like that. It clearly shows that the man only cares about how he becomes known around the community, otherwise why spend time on something like that when you know that people will laugh in your face with what you will show them??? People there where experts not just users and could not be fooled by few visual effects.

Again: Beryl != Quinn and Beryl != visual effects only. I don't know Quinn's reasonings behind going to XDC ... I'm also not sure if I would have gone there.


Anyway the point is that we spend resources for nothing and i believe that its only pride that stops at least a few beryl people to join us here, otherwise why bother answer our posts here??

You mean it's only pride that e.g. I don't join Compiz because I'm already talking to you? Seriously? :shock: Why shouldn't I talk to you while still working on a different project?
I thought I had explained my reasonings clearly earlier...


This whole big issue began just because a few people did not want to have their code checked by others, because they though that what compiz was a few months ago was all that it will ever be (core wise) but as we see things are diverting very much away from this.

Please stop repeating the old stories over and over again. This is tiresome; and if the Beryl-Compiz history has shown one thing, then it has shown that Compiz won't attract Beryl users by reapeating old stories again and again.


The only thing we miss is a central repository (outside xorg) to experiment with new things and then submit them for formal inclusion in compiz or compiz-extra, thats it.

IMO that's a critical point, but mileage may - as always - vary.


Now if people want to duplicate - fork code for educational purposes this is great but this does not make it a full project to replace compiz or any part of it. How many decorators are there?? I would have preferred if all these features like pulsing buttons and transparency where submitted to the existing decorators (even on gnome or kde) and not reimplementing them.

There is heliodor which is == gwd, and there is kwd, which is implemented based on aquamarine. Besides that, there is emerald, which is ugly code but provides nice decorations. I'd love an emerald compatible DM based on libdecoration.


The way things are going i do not see anything good coming out of this.I do not see many new plugins on beryl and it seems that they understand that visual effects are not the most important thing anymore but they do not know how to move forward.

Not many new plugins? You must be kidding... take e.g. wall which was appeciated by a lot of people.


I'd rather say that if an OSS-project needs to "recruit" developers at all there is some sort of problem. I guess I speak for all the compiz-devs and -users when I say that we stick with compiz because we want to, not because someone recruited us ... Wink

Looks like my English wording was poor ;)
Replace the "recruit" by "attract" and you get what I wanted to say.


The reason that beryl has more users and devs is that they (the beryl-officials) forced the whole compiz-community into a new project and a new name without making a single poll about it (I am a witness - it has all been decided outside the communities' visibility).

Well, no. That's not true. As nzjrs (or even you) has brought up in the Beryl forums a lot of Beryl users don't even know this history. They just use it because it has a settings manager included, don't need to fiddle around with plugin load order and things like --strict-binding and such. That clearly is an advantage and shouldn't be underestimated ;)
And about the devs - most current devs (namely me, marex, roico, racarr, pichalsi, onestone, KristianLy, I hope I didn't forget anybody) weren't active on compiz-quinn, but came to Beryl after the fork. I explained my personal reasons for choosing Beryl and not Compiz earlier. ;)


If people like working for a project that is built upon such immoral ideas and events - it's up to them ... I couldn't.

Well, that's up to you, but honestly, where do you see "immoral ideas"? Personally, I just chose the product which fits my needs best, at least in its current state.

[iznogood]

From the latest posts i can see that you have a positive attitute (snap plugin post) and you are working with us in the right direction of cooperation so the only thing i can say is welcome :lol:

[maniac]

From the latest posts i can see that you have a positive attitute (snap plugin post) and you are working with us in the right direction of cooperation so the only thing i can say is welcome :lol:
Thanks :)

[nzjrs]

I too would like to congratulate you on this newfound co-operation.

Kudos from me!

[delfick]

Can we please have a discussion without taking shots at beryl/Quinn. Maniac, delfick,

people take shots at me ?? :D :D :P :D


anyways, without getting into the technical side of things, i think compiz's popularity would greatly increase if it had a settings manager and window decorator to rival bsm and emerald........ :D

:D

[imnotpc]

You're absolutely right. David, myself, and some of the site admins have been discussing ways to reorganize and move the project forward. The top issues we've identified so far are: The design and usability of the site, the need for a full featured settings manager, improvements to the appearance and stability of the window decorators, and the need for a complete repository. We hope to post a draft of the plan shortly. It's a bit ambitious so once we layout the framework we're going to need help from all of you to make it happen.

[Alejandro Nova]

From all my research in the Compiz/Beryl holy war, there may be one point where Beryl supporters are absolutely right: comments. AFAIK, you can't lose so much time commenting your code, and making it understandable for others. Certainly this FLOSS project will benefit if we had more than one David, and David's mails are, by their own nature, slow. A better documentation for the code is something that can, and will, close positions between Beryl and Compiz camps.

However, if you ask me what is the best thing for me to use, the choice is clear. With Beryl... the magic lasts until I open Amarok. A single session of Konqueror with multiple tabs open is unbearable, the mouse pointer is patethically sluggish, while the animations are jerky and CPU usage rises over 30% (Sempron 2500, all with Emerald, I practically can't use Aquamarine). With Compiz... KDE Window Decorator is still buggy, but it kicks ass if I compare it with Aquamarine. CPU usage is stable at 3%, animation is always fluid, and the performance loss for 3D apps is A LOT less than Beryl. Compiz core IS better than Beryl's. And I can easily feel it. (Beryl 0.1.9999.2 vs. Compiz 0.3.6)

So, the best for all is: David (and someone who can learn from him), focus in the core, and the rest (plugins) goes to the community. And, with a code with better commenting and documentation, everyone wins. Please, include commenting and documentation goals in your plans ;)

That's just my humble opinion.

[nzjrs]

From all my research in the Compiz/Beryl holy war,

LOL, well put!

[karmapolice]

I just switched back from Beryl to Compiz and it feels faster but I really miss Beryl Settings Manager and Emerald.

I currently use metacity themes with Compiz but Emerald eventhough it wasn't the faster window decorator it provided a simple and easier way to edit a themes. I can create a goog looking theme in minutes but with metacity it is a pain.

The settings manager in Beryl is not the most beautiful app but it gets the job done faster and easier than gconf.

Anyway I'm enjoying Compiz again :D

[delfick]

You're absolutely right. David, myself, and some of the site admins have been discussing ways to reorganize and move the project forward. The top issues we've identified so far are: The design and usability of the site, the need for a full featured settings manager, improvements to the appearance and stability of the window decorators, and the need for a complete repository. We hope to post a draft of the plan shortly. It's a bit ambitious so once we layout the framework we're going to need help from all of you to make it happen.

awsome! :D

[FunkyM]

Some ideas:
Comment any source code on the way (add some words to functions "touched" by a patch or changeset)
Maintained compiz settings GUI (using DBUS maybe instead of gconf?)
Make it startup on first attempt with either NVIDIA, AIGLX or XGL (compiled vs. Mesa or not, use NVIDIA tfp or indirect rendering... etc.)
New next-gen decorator using SVG, arbitrary shapes, allow animation/effects, use blur and be modular
Unify Wiki and Forum Layout, seamless transition
Repository for compiz-extra and possibly other related projects
Supply me with WIKI editing permissions ;)

[mikedee]

Comment any source code on the way (add some words to functions "touched" by a patch or changeset)

Personally I think that documented examples and tutorials combined with the core functions (there are not that many) should do it. Things are changing drasticly at the moment, so it would be wise to make sure anything you document is actually going to stay that way :)

Maintained compiz settings GUI (using DBUS maybe instead of gconf?)

AFAIK it already uses dbus, I think dbus is now finished and can be used fully. The program is virtually done but it needs maintaining and updating/bug fixing.

Repository for compiz-extra and possibly other related projects

This is on my todo list. Again the recent changes in Compiz are not making it easy. There are some issues I need to work out and we will be losing some of the extra plugins unless they can be fixed for the new fragment function interface.

I have a tarball of everything I have working with current git. I just need to find the time to test them all.

[maniac]

Maintained compiz settings GUI (using DBUS maybe instead of gconf?)

AFAIK it already uses dbus, I think dbus is now finished and can be used fully. The program is virtually done but it needs maintaining and updating/bug fixing.

Are you referring to compiz-settings? If yes, this one looks nice, but is by no means finished: If there is a new plugin, it has to be added to compiz-settings because the plugin list as well as the option grouping is hardcoded. Much better would be to have it read the plugin list via dbus. Additionally, I think having the option grouping inside the options itself as Beryl does is a good idea.

Repository for compiz-extra and possibly other related projects

This is on my todo list. Again the recent changes in Compiz are not making it easy. There are some issues I need to work out and we will be losing some of the extra plugins unless they can be fixed for the new fragment function interface.

I have a tarball of everything I have working with current git. I just need to find the time to test them all.[/quote]
Heh, that's the disadvantage of not having a unified core <-> plugin repository ;)

[mikedee]

Are you referring to compiz-settings?

Yes

If there is a new plugin, it has to be added to compiz-settings because the plugin list as well as the option grouping is hardcoded.

Are you sure about this? As far as I remember it does load extra plugins from dbus. I remember seeing my experimental plugins in it when I used it last. I haven't used it recently because I know it would not work with current git.

Additionally, I think having the option grouping inside the options itself as Beryl does is a good idea.

I would disagree. I think its not good to have the internals of Compiz worried about how the settings are going to be provided in a GUI. One mans 'window management' is another mans 'basic features' is another mans 'WTF?'. All the extra options stuff that was added seems to have only been added so that BSM would not have to worry about that sort of thing (ie - it could be written as quickly as possible with as little effort as possible). Most of the options stuff in Beryl is unused or blank from what I can see.

I think a proper settings manager would need to be hard coded as all the ones I have seen so far just replicate the options without any real thought about the user interface or usability. It would take a lot of work though and it would be best to have a generic one first.

[maniac]

Are you sure about this? As far as I remember it does load extra plugins from dbus. I remember seeing my experimental plugins in it when I used it last. I haven't used it recently because I know it would not work with current git.

At least I couldn't find a reference to "getPlugins" in its source code. I only found the hardcoded values.


I would disagree. I think its not good to have the internals of Compiz worried about how the settings are going to be provided in a GUI. One mans 'window management' is another mans 'basic features' is another mans 'WTF?'.

Ok, then we have different opinions about that. My opinion is that the plugin developer knows best how to options are related to each other. With this implementation plugin and settings manager are independent from each other.


All the extra options stuff that was added seems to have only been added so that BSM would not have to worry about that sort of thing (ie - it could be written as quickly as possible with as little effort as possible). Most of the options stuff in Beryl is unused or blank from what I can see.

This isn't true. This was true when these additional entries were added, but isn't true now. As BSM is designed to present all the options (as opposed to BSM-Simple), my previous explanation applies ;)


I think a proper settings manager would need to be hard coded as all the ones I have seen so far just replicate the options without any real thought about the user interface or usability. It would take a lot of work though and it would be best to have a generic one first.
Well, I agree for a simplified settings manager (such as gnome-compiz-manager, which could ignore the option layout stuff). But for the geek guys (like us ;) ), I think a settings manager that presents all the options in a senseful way and does not need to be updated when there is a new plugin available would be very nice to have.