[compiz] The future of Compiz

[Danny Baumann]

Hi,

> > I think this is something we really need to fix as a community. Dennis
> > should have just been able to post a mail to the list saying 'Core is
> > broken,  I have time to work on it, here is a list of features I
> > propose', have minimal discussion, have him present to us a prototype
> > and if it works then we think about merging it. However, I really
> > don't think that would have been possible with the current kind of
> > community we have now. Notice how much of the argument so far has been
> > zealotry about a C++ based core? 'Ohhh, but look what Linus Torvalds
> > said, he called C++ "bullshit"' NOBODY has taken serious notice of the
> > other things compiz++ includes, which do fix some really broken
> > application-wise things about core.
> 
> The problem is that all these things were done together. Many of the
> features that Dennis have written are no-brainers when it comes to decide
> whether we want it or not, but C++ is a big step, and gambling everything
> on C++ being accepted and a success is wrong.

Agreed.
 
> > > - The code is undocumented, specially core, and not particularly pretty.
> > >  Even new code is added using this same style of no documentation and
> > >  functions that do more than C functions should do. This is not something
> > >  new, but even people who realize the problem are ignoring it.
> > >
> > 
> > Agreed. New developers need specifications on how core's interfaces
> > work and just saying 'Look at how other plugins do it' is just lazy.
> > 
> > As for the messyness and longness of code, I can think of a few
> > example that really need fixing straight away.
> > 
> > display.c handleEvent()
> > display.c addDisplay ()
> > screen.c addScreen ()
> > screen.c All output related code should go in output.c
> > window.c addWindow ()
> 
> All of these are functions I've been talking about for years. I started
> cleaning this up in Beryl right before the merge, but after the merge, I
> ended up waiting. First for things to settle, then for the object
> framework. That never happened and there was no decision as to what to do,
> and I ended up, like everyone else, in a watch-and-see mode.
> 
> We CAN fix this.

I know function lengths are a pet hate of you, but I don't think they
are our largest problem. Perhaps handleEvent () could be split, but
addDisplay (), addScreen (), addWindow () I'm not sure about.
Introducing new functions and source files not necessarily makes code
more readable.

> I really hope Dennis and Danny will comment on this thread ASAP, as they
> are the maintainers of Compiz. It would be nice with input from David too,
> of course, but to be frank, Compiz needs David to detach himself from the
> project so we can move on. It's sad, but it's the reality. Either that, or
> a major change in attitude towards cooperation.

I'm not sure what you want to hear from me, though? Of course adding
comments etc. is always appreciated, you don't need to ask for allowing
that. Same goes for all kinds of code cleanups, as long as coding style
is kept.

> I believe our first course of action is to establish a coding standard for
> Compiz and Compiz core. That's a coding standard that goes far beyond just
> how you name your variables and whether you use tabs or spaces. I'm talking
> about clear guidelines for what we believe is acceptable code in Compiz and
> what's not.

Do you have a proposal ready?

> Next I believe we should apply those standards to the branches we have, and
> look at how (un)acceptable they are, specially compared to what we have in
> Compiz master. We also need to look at what the benefits of merging these
> branches are, how they will be maintained over time, and the down sides.
> These branches were obviously started before any such standard was decided,
> but that's no reason not to require them to be updated prior to a merge,
> if not to meet all the points, then at least to meet the majority of them.

Yeah.

> After this, we need to decide down to earth goals for our next major
> release. What these goals will be will obviously depend heavily on what
> happens with the branches. I belive we should aim mainly to bring Compiz
> out of a constant research project-like state and into a production
> environment, regardless of what we do with the branches we have.
> 
> So who am I to decide what's acceptable and not? Well, I don't see anyone
> else doing it, so I guess that's my cue to take charge. If left unanswered,
> I'll proceed to post my suggestion for coding standards to apply to Compiz
> core in a day or two. 

Please go ahead.
I never intended to be a compiz maintainer, because a) I don't have
enough time to do it properly anyway and b) project management is not
exactly my biggest strength. I just seem to be the only person working
on compiz master lately :-/
If someone else steps up and manages the releases, I will be pretty
happy about that.

Regards,

Danny