Well, 1) was coded exactly at the same time as in upstream, and beryl
versionning is quite shorter in terms of code. The plugins have only
one new line... nothing more, while in compiz there's a new function
for every plugin.
2) The new coding style wasn't included to make things harder to
backport, and we're perfectly open to discuss this, as anything else.
3) We did not "intentionally" broke the gconf system. And we'll make
sure to reinclude it sometime in the future in an extra package.
We're not trying to do incompatible stuff, we're just trying to do good stuff.
As Colin said, the fork happened 6 months ago, the announcement last
month just "formalized" it. Furthermore this was thought as a
"friendly" fork, but some people are sadly trying to make it
unfriendly.

Just a quick note, this does not sound to be the right place for Beryl
critics, it's the compiz mailing list. What you're doing here is
somehow useless, it's just bad propaganda against Beryl. We're really
open to any critic/discussion, but not here ;)

Regards,
Guillaume Seguin

2006/10/6, Mike Dransfield <[EMAIL PROTECTED]>:

>
> (also, please note that I do not consider beryl as the fork, but the cvs
> versions many moons ago with extra patches applied - this was the fork
> and it's several months old - beryl is just a name change IMO).

I think this is where you are wrong, if you studied the code then you
will see a major
change of attitude and plugin compatibility since the beryl fork.

My 3 FACTUAL examples are

1) Deciding to implement their own versioning system which is slightly
incompatible
with compiz.  NO technical benefit whatsoever (in fact a slight
disadvantage).  They
initially tried to justify the decision by saying that the plugins would
need to be
modified, then promptly changed their design so the plugins had to be
modified.

2) The recent plugin communication system.  This adds a very big hurdle
to making
plugins compatible between beryl and compiz.  Also it means that beryl
has 2 different
ways of communicating.  PLUS a new coding style was introduced to make
things that
bit harder (Just as I thought that was 1 thing the 2 projects could
agree on).

3) Configuration system broken so that only csm works.  There is no
technical reason
why there should be only one settings manager.  People should be able to
use gconf OR
csm with beryl, but for some reason it was decided that csm was the only
option.
csm is flawed in a few respects.  This started a few weeks before the
fork, but has
continued along the same lines (making plugins incompatible).

Until the beryl supporters can come up with valid reasons for this and
my previous
issues then I cannot take them seriously and I dont think anyone else
should either.


_______________________________________________
compiz mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/compiz

_______________________________________________
compiz mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/compiz

Reply via email to