Kristian’s look on things

After several months of work, we are finally ready to present Compiz Fusion as a release, Compiz Fusion 0.5.2.

The version number is derived from the Compiz version number we’re basing the release on, and is a developer release. Just like compiz just branched 0.6.0, we will be branching Compiz Fusion 0.6.0 now too, in hopes to get a “stable” release out soon.

This is still an important release, being the first release we’ve made. I’m not going to try to sum up everything changed, see the official release announcement for that, but I do feel like mentioning what I see as the most important parts, compared to pre-merge Compiz and Beryl.

First, we are using Compiz as the core of this project. We have extended the functionality of the core Compiz package by adding the Compiz Configuration System (CCS). This comes as a plugin (ccp), library and settings editor (ccsm) for now. CCS has been given a lot of work, and will set the foundation for future configuration work. In Beryl, the configuration system was a part of the core, and not really as powerful as CCS is.

Though many of these issues had been solved in different ways in Beryl, Compiz 0.5.2 has several Multihead related fixes, both for using multiple X screens, and one big one.

There are also too many new plugins to mention all of them, but from my point of view, expo and color filter are the biggies. Expo allows you to view the content of all viewports with the touch of a button, and move windows. The combination of Expo and Wall makes for an excellent replacement of Desktop Cube/Rotate.

I like color filter for the accessibility factor. We have always said that Compiz and Beryl provided accessibility improvements, but truth be told, up until this point, those improvements have been more or less coincidental. There have been very little direct work to improve the situation for visually impaired, but Color Filter and Enhanced Zoom are just that.

Both Color Filter by Guillaume Seguin and Enhanced Zoom by myself are created with visually impaired in mind, and both are Google Summer of Code projects for Ubuntu. Color Filter is mostly useless if you are not color blind, but still a very important step. Color Filter allows a user to filter certain colors, changing blue with another color for instance. Enhanced Zoom will probably be useful for anyone, but the main target group is still the visually impaired. I hope these will not be the last explicit accessibility enhancements we see.

There are many other significant changes and features. Besides the ones I mentioned, I think the sheer number of new plugins and features in it self is an important point. So many small and large new features have been added

I also believe we are making very good progress as a project in general. The difference between former Beryl developers and Compiz extra contributors are fairly blurred at this point. The result has been an increased professionalism in the project, despite “a couple of” flame wars. I hope this can be seen from the outside too, and eventually be seen in the product we deliver. If you asked me two months ago whether I thought this merge was the right thing, I could not have given you a straight answer. I can now.

We just enabled merging of the Enhanced Zoom plugin (ezoom) with the Compiz Fusion “plugins-main” repository.

This will mean that any distro that packages our plugins-main will soon have ezoom. Including Ubuntu Gutsy.

While the Summer of Code project isn’t entirely finished yet, the large parts that are related to the actual plugin is. Before enabling the merging, a fix for expo-issues was committed, along with a change in the default key bindings so they don’t conflict (with expo, coincidently).

For those just tuning in, enhanced zoom is a Google summer of code project consisting of a Compiz plugin, with the shorthand “ezoom”, and work outside of the compiz plugin (orca/at-spi) for communicating events to the zoom plugin.

The ezoom plugin can:

• Zoom in as much as you could possibly want.
• Zoom in with input enabled.
• Track focus; the zoom area moves to newly focused windows.
• Fit the zoom area to a window. Either automatically while tracking focus, or manually with a key binding.
• Zoom in and use mouse panning when the zoomed in mouse cursor approaches the edges of the zoomed area. (An often requested feature of Beryl’s inputzoom).
• Resize a window to fit a zoomed area (Currently doesn’t move the window into place, however).
• Center the mouse in the zoom area on a key binding.
• Pan based on keyboard bindings
• Be controlled through dbus.

The main motivation for the plugin has been accessibility. That is: creating a plugin that helps visually impaired users. The work is by no means finished, but this is of course an important milestone for the enhanced zoom project. I hope this will help those who need it most. And those who doesn’t really need it, but find it convenient to be able to zoom.

Since the last blog post, I’ve added the locking/unlocking of a zoom area. Not yet as useful or tuned as it can be, but it’s a start. Next and last on the list for the actual plugin features is the saving/restoring of zoom areas which was supposed to be done by now, but focus shifted to getting ezoom into plugins-main.

I’ve been fairly quiet lately. Not too much code being released either.

The main reason has been summer, I’d have to say. What I’ve been doing is mostly experimenting with DBus, Python and AT-SPI. And general playing around with zoom.

Over the course of the next few days I’ll be:

1. Bringing “Sync Mouse” in line.
2. Creating a small plug-in for displaying information messages on-screen. This has to be a plug-in so we can see the text regardless of zoom.
3. Create functionality for locking the zoom area and storing/restoring zoom areas.

Most of that will probably be finished within 3-5 days. I need the extra plug-in to have a consistent way of displaying information about when a zoom area is stored, locked etc, but it should be used by other plug-ins too (Opacify for instance could use it to inform the user on when he/she toggles Opacify on/off). It’ll simply use the logging interface of Compiz.

I’ll also upload a little bit of code that gives ezoom the ability to move based on region of interest messages over DBus, similar to how gnome-mag gets what it needs from Orca. I’m sure you can see a pattern here…

On a different note, I’ve “had to” buy/build a new computer. It’s pretty crazy to see the BIOS report a CPU temperature of 19C when all I was going for was quiet… I literally can’t believe that temperature, considering that can’t be more than a couple of degrees Celsius above room temperature at the time… Nice having more than one core for a change though.

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 freedesktop.org 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 opencompositing.org 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.

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

There’s currently a poll on the opencompositing.org 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 opencompositing.org 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 opencompositing.org 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.

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.

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:

http://gitweb.opencompositing.org/?p=users/kristian/zoom;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.

The zoom plugin can now draw and scale it’s own mouse cursor, using XFixes to fetch the graphic. So far, it’s not very advanced as far as settings and such goes, but this also opened up a door for panning.

Since we can’t redirect the input, and the cursor is drawn by X it self, we are so far bound to the original placement and movement of the un-zoomed cursor. However, Quinn told me about an idea Dennis (onestone) had a while back while doing the inputzoom plugin for Beryl. The idea is simple: Instead of syncing the cursor and zoomed area, hide the original cursor and draw a magnified version of it where it would be if zoomed in. The result is that we don’t have to move the zoomed area around whenever the mouse moves, because the user can see where he is clicking anyway.

That might sound cryptic, so let’s try again: Zoom in to a window, move the mouse, it moves fairly quick (because it’s the original un-zoomed mouse movement) but the zoomed area does not shift, thus allowing you to focus on a window and click anywhere without having parts of the window go off-screen.

This is basicly a side-effect of drawing the mouse cursor in the plugin, and makes the plugin much more comfortable to use. There will be some improvements on this area over the next few days to make panning more natural and to avoid loosing the mouse outside the zoomed area.

PS: To test this, you have to turn OFF mouse syncing, and turn on drawing of a scaled mouse pointer. (And hide the original pointer if you like your sanity).

The easier parts of the zoom plugin is starting to look good now. I finally fixed the math for moving the zoomed area to an absolute area (as opposed to moving it with relative center in a point, which is needed for mouse movements) today, which was a must for anything that wanted to target a window.

In addition to this, the zoom plugin can now fit the zoomed area to a window, either manually or automatically if enabled and focus tracking triggers. What this means, is that you can make a window take up the entire screen at the click of a key, and with another key you can of course zoom right back out again. This combined with manual panning and fixed zoomed out by keyboard means that the zoom plugin is very very usable now without having to resolve to mouse movement.

I’ve also been reordering the code a bit to fit my coding style better, while the basic style has been kept. Mostly moving functions around, which is more necessary now that the plugin is getting more advanced. There are still some things I’m not happy with style-wise, but it’s getting there. It’s also humorous to spot obvious copy/paste bugs that exist in both compiz’ original Zoom Desktop plugin and the completely different inputzoom plugin found in Beryl.

Next on the todo is zooming the mouse pointer. I’ll have to use some tricks from Beryl here, and I’ll have to experiment a bit. I know this is a much sought after feature, so I want it to be as close to perfect as it is possible to get it.

When that’s done, I’ll get started on what I suspect will be the real time-stealer; at-spi integration.

Got focus tracking in place, it’s not perfect, it’s not polished, but it’s quite addictive. So what exactly is it? Well, zoom in on a window, say a 24*80 terminal, then switch focus to another terminal, and watch the zoom tag along. It’s a fluent animation, and you’ll even see your mouse move during the animation.

The mouse movement is necessary until we can redirect input. To understand this better, you can download my plugin and disable “Sync Mouse” , which will disable the syncing of mouse and zoom area, and leave you with an input that is practically unusable, since what you think you’re clicking, isn’t really there.

Also got fixed zoom factors working, and realized I could make a list of bindings instead of statically defining three after the fact. I’ll probably improve this when I get the time.

All in all a good few days. I am in no way satisfied with the quality of the code yet, but this experimenting is showing me what I need to fix, and is laying the fundamentals for the real work to come. The code is quite stable, however, so it shouldn’t be very risky to try it out.