Kristian’s look on things

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.

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.