On Wed, 2007-03-28 at 19:11 +0200, Kristian Lyngstøl wrote: > On 3/28/07, David Reveman <[EMAIL PROTECTED]> 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.
Don't worry, as long as we're open to other peoples opinions and interested in solving problems by finding solutions that we can agree upon, this shouldn't be a problem. > > > 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. With some small changes to the core, we could probably make it possible to implement this in a plugin. SLED and even though I haven't tested myself, I'm pretty sure there are some other distributions out there that allow compiz to run out of the box. It's just a matter of what hardware it's limited to. - David _______________________________________________ compiz mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/compiz
