Kristian’s look on things

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.

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 opencompositing.org 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 https://launchpad.net/compiz-zoom.

Recently, Guillaume (Known to most as iXce) and myself got accepted by Ubuntu to work on Compiz/Beryl in Google’s Summer of Code program. I’m thrilled myself, and can barely wait to get started.

We’ll both be working on accessibility features, Guillaume on color filtering and I’ll be focusing on zoom enhancements. As the situation with Beryl’s input zoom is a bit dodgy, one of my main goals will be to both provide input enabled zoom with the current technologies, and prepare for the future with input transformation. Some of the main new features to look forward to will be:

• Zoom follows cursosr
• Zoom follows focus
• Fit zoom to window
• Fit window to zoom

The idea is to make this as generic as possible, so there won’t be a need to implement major changes when input transformation is available to most users, and ideally it should work both with and without input transformation even when it is available. This will mean I’ll probably write a new plugin, which isn’t really all that much work. I’ll be using some of the existing accessibility technologies available, but still want this to work for users that otherwise don’t have to use accessibility technologies.

It’ll be interesting working on this, but it has also been interesting in a very diffrent way to see this merge between the Compiz community and Beryl. I don’t want to spark up any new flames here, there are enough of them allready, but I hope we can get something presentable out to our users soon, but it’s not looking too good. The work on core is going quite well, and there hasn’t really been any plugin issues either, it’s everything else that is causing delays. And I also belive this is causing us to loose a lot of development time. I know I haven’t been very active myself, though I’ve done a little work on porting/merging my multiscreen stuff.

I’ve been putting together a compiz-manager script which is far from finished, which I hope can help people start Compiz in their favorite way, autodetecting many of the options that Beryl does in core, but compiz doesn’t. Beyond that, I also intend to get a build-script out there for users wanting to use the git versions, but don’t know where to begin. I’m more or less just waiting for bset to get to a point where I’m happy with it, and you would be too.

My last post kinda looks strange with the merge going on, but at least something big is happening, and we’re going somewhere.