[compiz] The future of Compiz

[Kristian Lyngstol]

On Fri, Jan 02, 2009 at 01:33:44PM +0100, Danny Baumann wrote:
> > > 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.

Agreed. It's the complexity of a function combined with it's length that
can cause problems. Functions like addScreen are mostly just variable
assignment, and if they are problematic in length, that's a signal that we
have messy data structures. Just splitting up addScreen for the sake of
shortening the function does not solve the fundamental problem. And the
data structures would be last in line for a fix, as, hopefully, it would be
evident what needs to be done once the more obscure yet important
functions are tidied up.

An example could be focusDefaultWindow (first thing that popped up on my
screen), which evaluates and sets focus in a number of places and calls
functions that do the same.  The basic design makes sense, but the way it's
written makes it unnecessarily hard to follow. I'm also fairly sure that if
we split up functions like that, we'll find code duplication in a number of
places.

Reducing code duplication is important to improve consistency and reduce
the entry points into core, which, in turn, is important to retain
stability over time and avoid regressions. It will require a few
iterations, but the only way to effectively reduce code duplication, is
splitting up relatively complex functions.

> > 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 just want to make sure I don't step on your toes in any way, because I
value your opinion highly. We don't have any official "project owners" any
more, but you and Dennis are the closest thing we got.

> > 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?

I'm formulating one, I'll have a draft out in a day or two. I was hoping
from similar input from Dennis, and it's taking a bit longer than
expected. I re-started it yesterday to combine it with coding style, so
that we get one unified document.

> > 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 :-/

You're not the only one who feels this way. I'm glad you and Dennis have
tried to keep core in running shape, and I hope you'll continue to
contribute. 

I honestly believe we can revive Compiz fully in 2009. I don't see any
significant disagreement with the suggestions I've made, but words are
cheap.

- Kristian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/compiz/attachments/20090105/991069d0/attachment.pgp