[compiz] The future of Compiz

[Sam Spilsbury]

On Mon, Jan 5, 2009 at 6:55 PM, Kristian Lyngstol
<kristian at bohemians.org> wrote:
> 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.

It might be worth having a good look if compiz++ has solved some of
the more fundamental issues with core structure complexity, especially
CompScreen.

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

Speaking of which,

I had a chat to onestone on IRC about modularising a bunch of useful
functions that people just copy'n'paste into other bits of code and
having them in a kind of libcompizfusion.

Would that be worthwhile? There is a blank wiki page to edit for this
at wiki.compiz-fusion.org/Development/Proposals/LibCompizFusion

Good things to include would be:

 * Extra matrix functions (matrix division, inversion, projection,
bias stretch etc)
 * Mesh interface for modelling
 * Multi-list handling like in wallpaper.c (even if it does look a bit
like dark magic)
 * Viewport switching interface *cough*

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

Will this be posted in a new thread?

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

I really hope that this conversation doesn't just die off like a lot
of the other conversations we have on this mailing list as we simply
'wait' for more contributors. As for reviving compiz, if we want any
viable future to do this, it needs to be done fast - a lot of
distributions are considering adopting metacity and KWin over compiz
right now.

Another thing too. I think that we need to get into the habit of
setting deadlines for desicions and code submission and also
communicating if those deadlines cannot be met. Right now we have this
willy-nilly structure of intense discussion that suddenly drops off
with no actual conclusion reached. We need to stop procrastinating by
using excuses like 'We'll see what X contributor has to say about
this', especially when they are more or less inactive. If there is a
reasonable agreement amongst the majority of _active_ contributors,
then the decision should go ahead. Efforts should be made to try and
get a hold of everyone possible, but when push comes to shove the
project needs to move forward. If you are going to be away and don't
want the community to pass something big without your say but will be
away, let the list know that you _are_ away and make some kind of
effort to be in-contact.

Best wishes for the new year,

Sam

>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFJYdj18aD+nxnFLQIRAnXTAJ4lFUPJl7FCa7mvMuWAceU8+qVExwCdEHTB
> sOYbqRvO0/TE4k4Xnal8Wxw=
> =9jj6
> -----END PGP SIGNATURE-----
>
>



-- 
Sam Spilsbury