Kristian Lyngstol's Blog

A free software-hacker's blog

Tag Archives: Beryl

Then there was a name: Compiz Fusion

After a lot of back and forth, some fumbling with a vote and a lot of suggestions, we finally managed to find a name. Compiz Fusion. There are a lot of people relieved that we finally managed to find a name. Myself included.

We ended up weighing developer/contributer opinions higher than the users in this specific issue, after all, this is our work we’re naming. But the process was made in such a way that we found a name that the most developers didn’t dislike. Sort of the opposite of a vote for a winner. The plan was to have the users decide between the remaining names, but in the end, there wasn’t really any names remaining.

Personally, I’m very happy with this method. I never thought it would take this much effort to find a name, but the users should know that we spent a lot of time on finding this name, and every imaginable option was explored. There were a lot of concerns we had to honor: We didn’t want a name that was a “morf” between Beryl and Compiz (Like Coryl, and many also felt Coral was just this). We also had to honor the wishes of the people who will work most with the name.

There are still a lot of things we need to decide, and it’s not easy. There are still many hot debates going on, or that will have to be started. We need to decided what to do with forums, domain names and whatnot. Besides that, we have to find a more permanent way to manage the project.

Code-wise, we’re going forward, luckily. So most of this is tiresome squabbling. But we still have to deal with it, and there are some issues with how we’ve worked on code too. Many of us feel we need a more proper planning phase for the development process, this is specially true for the settings system, which was developed by a close group of former Beryl developers. This isn’t something unique to the Compiz Fusion project though, we kinda wanted to do that in the Beryl Project too, and many of us feel it’s a valid point in the Compiz development cycle too.

Now that we have a name, packagers are getting to work. Guillaume (iXce) and Alex (nesl247) on the Beryl side of things are sorting out git-renaming (yet again) and forum work, Dennis (onestone) seems to be doing the build-tuneups, and all of will probably adjust our individual code bits to fit to the new name. Because I tend to stay away from the longer arguments on the mailinglist, I haven’t really spoken to Rico lately, but I hope he can get to work too, even if he’s not exactly best friends with all the other developers and contributors at the moment.

So, for those who’re confused:

Compiz – The original project. Now only the core and a select few original plugins, located at and the main developer is still David Reveman.

Beryl – A discontinued fork of Compiz, after “compiz-quinn”, a community set of patches, had drifted too far apart from the original project. Introduced many features, both in the core and outside. And attracted many developers. And the fork it self was the source of much debate.

Compiz Extras – A sort of “division” consisting of the people who worked on compiz, but the extras were not core-fixes. The concept is similar to what made Beryl what it is, but also very different. It was to include a wider set of plugins and tools. Now discontinued.

Opencompositing – A common name used for the merged project and more, does not include the core. This was meant mostly as a temporary name, but what becomes of this terms has yet to be decided. It will most likely be dropped.

CompComm – Another name for the merged project, not including core, more of a shorthand for “Compiz Community”. The git repositories sported compcomm/ prefixes, this was mostly done for practical reasons. This name will be discontinued entirely.

Compiz Fusion – A community project forged by the merge between the Compiz Extras and the Beryl project. This does NOT include a core, as the core changes in Beryl are either being scrapped, or re-written for the core Compiz project. Compiz Fusion will sport settings tools, more plugins, helpfull scripts to start Compiz with the Compiz Fusion plugins, and basicly anything related to Compiz that’s not the core.

Naming a project, steering it

Beryl and Compiz are merging. Compiz will remain the name for the core. For everything else we need a new name.

There’s currently a poll on the forum.

There is also a lot of complaints on how this is done. Some people don’t like one name for whatever reason, others do. Some people feel they weren’t heard and their alternative should be on the vote. Many people calling for stopping the vote.

Well, as it happens, I’m all for democracy, but this is ridiculous. The people who should be responsible for naming a project, is the creators of the project. Not everyone and their dog. And we can’t wait around forever for a name. The name is important, but it’s even more important that we get one, and fast.

Personally, I voted for Coral. I’m not particularly happy with it, but in my opinion, it’s a name most people can accept. I don’t care that there are other projects with similar names. Coral is something growing in the sea, that’s where it’s from, not “stolen”. And I don’t think discussing names for a few more months is going to yield any happy results.

I am amazed by how many opinions everyone suddenly has on a decision on the name. It doesn’t change anything, except it allows us to FINALLY get a web page, wiki and more with the proper branding. I urge the people who are giving their opinions on this to think twice. We want a name, we want to hear what people have to say, but in that order.

As for claims of lack of information, that’s utter rubbish. No, we did not advertise this in your local newspaper, but the fact that we needed a new name has been well known since we started talking about a merge. The vote has also been somewhat discussed on the “compcomm” mailinglist, and there was a thread on the forum prior to putting up the post. And names like Coral, CoCo and Blitz were suggested long before the vote came up for discussion, and they have been loosely discussed among the developers. If anyone has strong feelings about this project, they’ll know how to find this information. If anything, the problem with is that there is too much discussion going on, it takes forever to make any sort of decision.

There are also a lot of helpful individuals wanting to give input on how the project is steered. We do have a lack of leadership. There are two communities in play here, and neither wants the other to “take over”, thus making it difficult to find a leader we can all agree on. But it’s not like we actually need one. The Beryl project had Quinn as a leader, but in reality, she did not try to steer us. So far, we’re working on separate parts, and then there are individual leaders for each “sub project”. These are not announced as leaders, it’s just the natural way of working: Whoever works most on a project, is the one people talk to about it.

We will be working on non-developer teams soon. We’ve already put together a support team for the forum, which seems to work well (These guys deserve their own tribute-post, but that’s for a later date). When we have a name, we need wiki and web focus too.

What concerns me is the low and often negative participation in this joint effort from (former) members of the compiz community. It is not strange that opencompositing resembles the Beryl project, when all the input we get from the Compiz community is that it’s a silly idea and that we should just stop and do what the compiz community guys did before the merge (which I personally don’t think was much). I beg these individuals (you know who you are) to sign up on the forum, send ideas instead of criticism to the compcomm list and help us! We can’t create a merged project if only one party has their heart in it.

I for one don’t WANT a new Beryl project. I liked the beryl project, but it’s time to move on. We can’t do that without new ideas. But let’s talk about what to do, instead of talking about what not to do.

Whatever happened to the future of beryl ?

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 80×24,
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 “” 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.

Input enabled zoom!

After a little bit of hacking, I’ve got the original compiz plugin working with input enabled. Since the plugin doesn’t get MotionNotify events when input isn’t grabbed, it has to fetch the motion from other places though. So far I’ve solved this by fetching in DonePaintScreen() which works very well for me, but both common sense and early reports indicate that it’s not enough. The result is a little choppy.

The solution should be fairly simple. Either just add it to a timeout, which is what Beryl’s inputzoom plugin does, or… Ok, I guess that’s the only real option I can come up with, except modifying core.

In addition to enabeling input, I’ve also gotten basic focus tracking up. This is by no means well-implemented yet, nor am I satisfied with it. There’s two major issues:

  • It’s simply annoying.
  • The function for setting the zoom area to a specific area is bugged

The first problem is a fundamental problem that will probably take a lot of tweaking. So far I’ve added a hardcoded delay (which will be configurable soon) in when to activate focus tracking. This helps avoid jumping around when sloppy focus changes the focus, as focus tracking won’t do anything if the mouse has recently moved. This is a fairly reasonable way of doing things, that I’m happy with. I also intend to add a few other mechanism for making the focus tracking more natural. The lack of input transformation really underlines this problem too, since the mouse pointer will jump whenever the zoom area is moved. However, if input transformation was implemented, it would be trivial to disable this mouse wrapping.

As for the bugged zoom area function, that’s another story. Basicly, I’ve come to the conclusion that I can’t actually do math while sitting in front of a computer. Right now, the function works after a fashion, for the first zoom level it’s also precise. For any other zoom levels, it misses a little bit. This is what I’ll be working on next.

I still haven’t decided wether this will be an entirely new plugin, or to attempt to get it accepted into the compiz core package. Since it will eventually rely on AT-SPI, I am not sure it makes sense to attempt to get it into the core compiz package, and this is exactly what is for, anyway. Either way, it’ll be easily available to anyone wanting to use it.

As a last note, I’ve set up a launchpad project for google summer of code. So far I haven’t actually started using it, but I intend to use it. You can find it at


Get every new post delivered to your Inbox.