Kristian’s look on things

May 30, 2007

Mouse cursor scaling and drawing

Filed under: Summer of Code, The GNU/Linux Desktop, opencompositing — kristian @ 10:22 pm

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).

May 29, 2007

Fit zoom area to window, manual zoom panning and bug fixes

Filed under: Summer of Code, The GNU/Linux Desktop, opencompositing — kristian @ 12:00 am

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.

May 23, 2007

Zoom with focus tracking and fixed zoom factors

Filed under: Summer of Code, opencompositing — kristian @ 2:38 am

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.

May 20, 2007

Whatever happened to the future of beryl ?

Filed under: Beryl — kristian @ 4:00 pm

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 “opencompositing.org” 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!

Filed under: Beryl, Summer of Code, opencompositing — kristian @ 4:44 am

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.

Powered by WordPress