Re Beryl and Compiz Merge: What's actually going on?

Hello Kristian,

Thursday, March 29, 2007, 12:11:41 AM, you wrote:

> On 3/28/07, David Reveman <davidrnovell.com> wrote:
>> I think you're making this into a bigger thing than
what it is. Lets
>> focus on solving the technical part first, most
importantly move to
>> having one core. I'm only talking about the code
that's currently built
>> into the compiz binary, none of the plugins.
Merging plugin code is not
>> nearly as important as the move to having one
core.

> Specially since most of the plugins are more or less
the same anyway.
> I would consider it mostly a non-issue. There are
obviously some
> differences, but those shouldn't really be that hard to
figure out on
> a plugin by plugin basis when the core is merged.

>> We're not very far away from having one core as I
understand. There's
>> clearly not 3 times as much code in beryl core as
in compiz core, you
>> must be talking about plugins here. The differences
that been brought up
>> to me have all been minor changes that I don't see
any reason why they
>> can't be resolved.

> I couldn't really get those numbers to add up either,
all I can
> imagine is indentation differences? Unless
libberylsettings is 50k LOC
> or something else equally crazy.
> As far as I can remember off the bat, there is the
recently added
> beryl logger code, which is quite small, the paint
attribute locking
> mechanism, some multihead changes, copy rendering, some
differences in
> settings, and maybe some other things I've forgotten,
but nothing that
> would double the amount of code.

>> The merge is done by moving changes made to beryl
into compiz or by
>> adding alternative solutions to compiz. No changes
are made to the
>> design of compiz and 99% of the code is still code
being written as part
>> of the compiz project so I'm having a hard time to
justify a name change
>> of the core and I know that most people in the
compiz community are
>> firmly against such a name change. A more plugin
oriented side-project
>> under a new name could make sense, though. Like
what compiz-extra is
>> supposed to be but my opinion is not as important
here as I'm not as
>> involved in that part.

> Personally, I would prefer a name change for the sake
of the community
> (People are sheep, if they see Beryl disappear and the
compiz-name
> remain... well, you get the point), but it isn't an
agenda I'm going
> to push. A name for the whole package might be an idea.
I know this
> will never be a DE, so don't take this the wrong way,
but much like
> how GNOME has Metacity... Or Debian has Linux at the
core, for that
> matter. While you would generally never use Debian
without Linux (IE:
> Plugins without Compiz), it's possible in theory. I
guess that sort of
> separation is what you were aiming for in the first
place?

>> Regarding leadership, having anything but a
technical leadership of the
>> core where the people who write the code and the
people with most
>> knowledge gets to decide is silly to me. Community
leadership, who's in
>> charge of the web site and such is a different
thing and maybe a bit
>> harder to solve but I'm sure it can be worked out
in time.

> I think there's a common misunderstanding here. I don't
think anyone
> really wants a person who doesn't contribute a
significant amount of
> code to lead the project. But at the same time, we're
(at least I am)
> a bit afraid of letting a single person have
veto-powers. An informal
> understanding that the lead developer could be
overruled if there is a
> large majority of other developers who disagree with
him is most
> likely what we're after. Again, those people would have
to actually
> work on the core actively, and there shouldn't be a
need for a too
> strict set of rules here. If you say you're OK with
this general
> concept, that's fine by me.

>> The technical part of the merge seems pretty
straight forward from my
>> point of view and I've got the understanding that
so is also the case
>> for the main contributors to the core of beryl.

> Yeah, mostly.

> There is one issue I'm a bit concerned about myself
though, and that's
> the infamous copy rendering.

> I know it's "broken by design", but the
number of times this has come
> in handy for users is hard to count. While there are
often ways around
> it, most users aren't concerned about the extra
resource usage this
> introduces if it "just works" until their
driver is fixed (for
> instance), and gets them out of several hours of trying
to find the
> proper solution.

> If we could find a way of keeping it without reducing
the quality of
> the code when it's not being used, that would be
something I think our
> users would appreciate. Maybe a build time option, if
it's practical?
> I don't know the details of the implementation in Beryl
beyond what
> I've seen in the damaging code and partly the texture
code, but it
> seems to me that it wouldn't be too hard to leave it in
without
> reducing the overall quality.

> The way I see it, the biggest problem with both Beryl
and Compiz from
> a users point of view is the hassle of getting it to
work. The
> situation with drivers and possibly the need for Xgl,
combined with
> the amount of different terms and technologies seems to
be the major
> reason why users hesitate to start using Compiz/Beryl,
and I believe
> copy rendering has helped improve this, even if it is
not the ideal
> solution. It will be quite a while before you can
"just install"
> Compiz/Beryl and  have it work out of the box, but
having copy
> rendering until that time doesn't strike me as a bad
idea.

>> - David


I'm a regular user and I do not need the second vista like
beryl. I
tried both beryl and compiz from latest git and svn: compiz
is really
much faster than beryl in the same configuration and plugins
set. I
have too old video card (mobility radeon 7500) and compiz
proved that
my card can be used more efficiently, beryl did not, beryl
says me:
hey man, buy new laptop with the video monster ;)

Compiz source code is beautiful, I will be very glad if
there is new
general option in the gnu indent: -compiz ;) I will
immediately apply
indent -compiz to the all my code. I am viewing community
patches to
the compiz and wondering: is it difficult to follow compiz
code style
rules? Respect David, he is wonderful hacker. He tries to
make your lifes
easier offering such perfect code.

Do not merge monster with garbage.
Compiz, stay clean.



-- 
Best regards,
 Denis Latypoff                          mailto:latypoffyandex.ru

_______________________________________________
compiz mailing list
compizlists.freedesktop.org

http://lists.freedesktop.org/mailman/listinfo/compiz