Kristian Lyngstol's Blog

A free software-hacker's blog

Category Archives: opencompositing

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.

Multihead updates and mouse panning

As I mentioned in my last update, I’ve been focusing on improving the normal multihead support. It required some minor and anticipated refactoring of the code that has now been completed.

I expect there to be some minor glitches, I’ll try to squash them as I spot them, but for now, it seems to work well. Zoom can now zoom individually on each head, and it should deal with the mouse correctly, and set the zoom level/target correctly when targeting a window. If you are using multiple heads, let me know if there are any improvements you feel I should make here; Due to the unusually warm days we’ve been having in Oslo the past week, I’ve been doing most of my work outside in the shade, and thus have not been using multihead as much as I would’ve wanted.

An added benefit of the refactoring is that it will now be fairly trivial to store and restore zoom states on the fly. The changes moved the state of a zoomed area into it’s own data structure, so it’s now only a matter of storing a copy of this somewhere and later restoring it, to set specific zoom-targets in a very proper and generic fashion.

I’ve also added some mouse panning code and restraining. The restraining is not pretty: I can’t grab input, nor would there be any window (though I could create one) to restrain the mouse to, so I’m left with warping the pointer whenever it moves outside of the visible area until I come up with something better. Mouse panning seems to work well, though: By moving the mouse outside the zoomed area, the zoomed area will tag along. This has introduced some minor glitches I’m currently tracking down, but nothing too serious.

Along with this, I’ve also had an API of some sort in mind while working. I haven’t come up with something specific yet; I’ve gotten a few good mails with advice on how to proceed, and I’m keeping all doors open until I’ve played more with AT-SPI/ATK, Gnome-mag and Orca. The code I’m writing is getting more and more suited for implementing an API though.

As for current plans, I have to focus on my last exam in economics on Thursday. Somehow, the PHP exam last Monday and databases exam on Friday required less preparation than the only one not directly related to computer technology. I expect be doing some minor tinkering and experimenting with AT-SPI and DBus along with tweaks and polish when possible, though.

Current state of Zoom and TODO

I’ve implemented a lot of features, most of them work well.

At the moment, the plugin is somewhat bugged on “bigscreen” multihead (which is what most people have; xinerama, twinview, mergedfb, etc). This will be a priority for me to fix over the next few days, it shouldn’t be too much of a bother.

Also, the drawing of the cursor uses XFixes. And XFixes is not really that safe. There seems to two fairly grave issues with XFixes that affects my plugin: Cursor simply disappearing on certain cursors (animated ones seem to be a sinner), and X crashing.

The “good” news is that X crashing seem to be related to my multiscreen setup (This is NOT xinerama/twinview/mergedfb). I have not been able to reproduce this on single-screen, and as I’ll be working with twinview the next few days, I’ll quickly discover if this is multiscreen related or not.

The disappearing seem to be a known issue. I intend to ask for some assistance on both these issues, so the plugin can at least tell when/if the mouse cursor disappears.

Other than that, the code is in fairly good shape. I’ve put effort into making things generic, to avoid having to re-do too much even when changing the way the actual zoom is performed. I’m at the end of what I can do without acquiring new knowledge, so this is where things will get interesting.

So, my todo:

  • Fix bigscreen multihead (twinview/xinerama/mergedfb/etc)
  • Narrow down the cause of the X crashes (feedback if anyone else can reproduce this is wanted)
  • Mouse based panning
  • Determine how to go about integrating the plugin with AT-SPI (gnome-accessibility can expect an e-mail from me)
  • Test ZoomText
  • Possible workarounds for XFixes loosing the mouse cursor
  • Quick-store/restore of zoom levels/position

This is probably not complete. I estimate the interesting parts will be AT-SPI integration and possibly dbus. I’m ashamed to admit that I’ve never bothered playing with dbus even though Compiz and Beryl has had support for it for the longest time.

For the interested parties, my code can be found at:;a=summary

Features the zoom plugin has:

  • Floating zoom (default: Super + mouse wheel). Existed in the original zoom plugin.
  • Fixed zoom factors (default: Super 1, 2, 3. Zoom to: 100%, 50%, 20% (100% == completely zoomed out))
  • Focus tracking
  • Input enabled (Both borrowed from inputzoom from Beryl, and improved with an idea by Dennis/Onestone)
  • Fit zoom level to a window (Can be activated on focus tracking. Default: Super r)
  • Fit window to zoom level (Resizes the window, does not move it. Default: super v )
  • Keyboard panning (default: super qwes)
  • Center mouse on screen (Default: super+c)

I should mention that my exams just started with the first one today (Monday 4th), so parts of my attention will be diverted to those. By June 14th I’ll be finished with exams.


Get every new post delivered to your Inbox.