Posted on 2007-05-20
One day I'm writing about all these changes I want to make in Beryl, and the next day Beryl is merging with the Compiz community. So whatever happened to my vision? Was it just talk? No, it wasn't.
There were a few improvements made to the Beryl core. I consider the idea behind the "Beryl logger" important; It made debugging a lot easier. It will also help new developers, and track strange bugs that the development team can't reproduce. It helps to increase the understanding of how Compiz works.
I also started cleaning the event code. Splitting it up. I spent a great deal of time experimenting to find out what really had to be inline and what didn't. Looking back, I wouldn't want the current state of the Beryl event code to be released as a stable release, but I think it's the right way to go. The changes I made were not bad, but it wasn't finished.
So far, these changes has not been merged. I belive what I did with Beryl in this area gave at least myself some important experience on the real flow of the code. I hope to use this to eventually improve the Compiz core too.
A few people seem to have misunderstood my ideas though. I belive David's overall design is pretty sound, but I'm just not happy with the state of the code and the lack of documentation.
Instead of trying to explain what has been explaind countless times before, let me quote Chapter 6 of the Kernel's CodingStyle Document, I'm sure you can find similar explanations in any document that deals with C coding style.
Chapter 6: Functions
Functions should be short and sweet, and do just one thing. They should fit on one or two screenfuls of text (the ISO/ANSI screen size is 80x24, as we all know), and do one thing and do that well.
The maximum length of a function is inversely proportional to the complexity and indentation level of that function. So, if you have a conceptually simple function that is just one long (but simple) case-statement, where you have to do lots of small things for a lot of different cases, it's OK to have a longer function.
However, if you have a complex function, and you suspect that a less-than-gifted first-year high-school student might not even understand what the function is all about, you should adhere to the maximum limits all the more closely. Use helper functions with descriptive names (you can ask the compiler to in-line them if you think it's performance-critical, and it will probably do a better job of it than you would have done).
Another measure of the function is the number of local variables. They shouldn't exceed 5-10, or you're doing something wrong. Re-think the function, and split it into smaller pieces. A human brain can generally easily keep track of about 7 different things, anything more and it gets confused. You know you're brilliant, but maybe you'd like to understand what you did 2 weeks from now.
So what's next? I'm not sure I'll be working too much on the Compiz core in the immediate future. A few multihead related things, but nothing major. I do have my zoom project to consider, after all. I hope I can get back to my original plans eventually.
As for the future of Beryl, we'll continue to support the stable Beryl branch (Beryl 0.2.x) for some time. This means critical bug fixes to keep it running, and user-support to a certain degree. When we're ready to release something under the "opencompositing.org" brand (No, we don't have a name yet... sigh), I figure we'll stop supporting installation-problems with Beryl from sources other than official packages bundled with distributions.