GNOME.org
 

Re: Compiz + A11y Discussion

Hi Shawn:

Welcome!


ZoomText and a few others that were short lived.  I hate to say it but
my primary system is MAGic on Windows XP.
Don't worry about hating to say it. You need to use what is most effective for you. By speaking up, however, you can help us improve things on GNOME. :-) So, it's nice to hear your voice. 


1. Magnification should have equal priority to speech when it comes to
usability. Right now every time I install ORCA / GNOME-mag on a system, 
one very important hotkey is not defined. The key to toggle
magnification on / off without exiting ORCA. There are many others also 
not defined.  This will lead into another point later.
You should not need to quit Orca to make the magnifier start/stop. Checking the "Enable magnifier" checkbox in the Orca preferences UI should toggle things without restarting Orca.
By "not defined", I'm not sure if you're referring to a feature not being provided or if it's a feature that is provided/supported, but not enabled by default. There is an unbound function in Orca to toggle the magnifier on/off. You can bind a keystroke to this function by going to the "Keybindings" tab of the Orca preferences UI and binding a keystroke to the "Toggles the magnifier" function. If you'd like this to be bound to something by default, please open an enhancement request for Orca at http://bugzilla.gnome.org and suggest a keystroke. 


2. Compiz is in general very smooth moving around the screen when
magnified.  It has hotkeys for some of its functions.  However the
versions up to the version in Ubuntu 8.10 do not track the keyboard and
most focus changes. This means that I spend a lot of time "playing find 
the cursor" as I often type out of the view.
The eZoom feature of Compiz is also missing a lot of other usability features as well. But, it does provide pretty quick refresh rates and easy ways to zoom in/out quickly.
As an aside, from the magnifying bits point of view, eZoom and gnome-mag are really quite close in how they do things. Both have their plusses and minuses, though. 


3. GNOME-mag has made major strides in my eyes over the last year. Most
of the time cursor tracking works. It no longer magnifies the magnified
view if you move your mouse into a wrong location.  However, on good
hardware it is jerky when it is following the mouse.  This can be and
often is very nauseating to people who have problems with motion
sickness.
For a quick clarification - you might be conflating Orca and gnome-mag. gnome-mag can run standalone using the 'magnifier' command, but it is somewhat restricted and offers limited use. Orca starts the magnifier as a service that it can control and then talks to the magnifier using CORBA.
IMO, the mouse tracking when using the combined orca/gnome-mag solution would be made a lot smoother if we could get this enhancement request addressed: http://bugzilla.gnome.org/show_bug.cgi?id=522967. 


 Also on all of my machines (various video cards, and various
versions of GNOME) I have a second mouse pointer, as if the non
magnified mouse is still visible.
If you go to the "Magnifier" tab of the Orca preferences UI, there's a "Hide System Pointer" checkbox. This turns off the system pointer. It's unfortunate that we need to do things this way instead of doing it automatically, but there are some problems with doing it automatically. Firefox, for example, has issues when we do this -- it can make the pointer disappear completely when you exit the magnifier. So, we make it an option to give you the ability to make the choice about whether you want to live with some applications becoming totally screwed up or not. :-( 


4. Text smoothing in both has improved to my eyes at least.  This is
important to someone like me who is in front of a machine for over six
hours at a time.  Less "brain stress" recognizing fonts and text.  The
problem with the current smoothing is that it sometimes makes text
appear to have blurry edges.  This is off-putting, especially if the
reason you are using magnification is you have blurry vision.


Agreed.


1. Have some sort of documentation project so that keyboard shortcuts
can be looked up by developers so that some of the overlapping of key
use can be eliminated. Once this moved forward a bit, trainers and end
users could use it as a reference guide.
Which keyboard shortcuts are you referring to -- the control of the magnifier, the control of the window manager, the control of the application, everything? The hard part I've seen with these kinds of documents is maintenance because they are drawn from multiple sources created by teams that don't communicate with each other. It's like the weather in New England - wait 5 minutes and it will change. Ideally, it would be nice to have this kind of thing automagically generated on the fly. 


2. Magnification needs to be done in two layers:
     a. The Application layer:  This is where I see Orca and GNOME-mag
right now.  They are very good at talking to applications and handling
events.  In          a lot of cases this is the only place you can do
tracking.  Communication with applications are key for getting the most
useful data.
    b. The Composition Layer: I believe this is the correct name for
where Compiz does it's work.  Here is where your actual magnification
should take place.  At this level you have access to overlaying the
screen, video acceleration from hardware and other X11 functions.  With
better and faster video chips out now, why not offload those movement
and other functions off the main processor as much as possible.
gnome-mag has COMPOSITE support in it, and is what is used when you are in the full screen mode in Orca. So, things really are being done in two layers -- Orca is doing things at the app layer and it is communicating with gnome-mag, which is doing things at the COMPOSITE layer. 


3. Communication between those layers is what I think may be the hard
part.  I don't know much about how D-bus works, but since it has become
extremely standard on Linux systems, It is what will be used most
likely.  I don't know if it has a real-time priority for handling
traffic but it may need it to keep speech and magnification synced up,
or even quick keyboard actions.
The communication between Orca and gnome-mag is done via CORBA, though Bonobo/CORBA have been marked for deprecation. So what we're dealing with is a bunch of stuff:
* There currently is no active maintainer for gnome-mag. This makes it difficult to plan for doing something like migrating the transport from CORBA to D-Bus.
* The COMPOSITE extension wants just one COMPOSITE manager. In the gnome-mag case, gnome-mag wants to be it. In the Compiz/eZoom case, Compiz wants to be it. I believe this can cause contention between gnome-mag and Compiz.
* IMO, eZoom provides zooming features that work really well for people who typically do not need to rely on magnification. That is, it's good for people who want to temporarily get in for a quick look at something. For people who need to use magnification as their primary means to access the display, however, eZoom lacks a lot, IMO. 

The path I've been trying to take is this:
1) Don't put all of our eggs in one basket. That is, don't depend entirely on gnome-mag or eZoom. Instead, define a magnification service API that's acceptable to modern thinking (e.g., D-Bus) and put support into gnome-mag and/or eZoom to support that API. With this, we'll end up with a decent API and at least one solution that supports it. Note that I'm not pushing one or the other of gnome-mag or eZoom. Both have their plusses and minuses.
2) Focus a lot on the division of labor as mentioned above. Something like Orca or a standalone magnification solution should be able to operate at the application level and communicate with a magnification service operating at the lower graphics level. The division should be done such that things can operate in the most performant way possible.
3) When working on the API, focus on features needed by people who need to use magnification as their primary access mode. Also, look to support features for highlighting portions of the screen and/or individual objects. Font substitution/rerendering may also be another thing to consider.
Now the reality comes in, which is that there's definitely lots of stuff to talk about and design. That's unfortunately the easy part. The hard part is getting people to do the work. We're currently looking at creative ways to resource the effort, and I hope we'll have something soon. 

Will



I hope this made sense.

Thanks,
Shawn


Willie Walker wrote:

Hi Bryen:

I don't believe the problem is a conflict between Orca's keys and
Compiz's keys. Instead, the the two different problems are that Compiz
causes events to be delivered in a very strange order when switching
between windows and that people have not been successful in using the
keyboard to navigate to the top/bottom panels and the desktop.

Will

On Mar 5, 2009, at 8:27 AM, Bryen wrote:


On Thu, 2009-03-05 at 07:57 -0500, Willie Walker wrote:
For Orca users, the two main bugs are the Alt+Tab problem that causes 
Orca to  be somewhat silent
(http://bugs.opencompositing.org/show_bug.cgi?id=1027) and Ctrl+Alt
+Tab
not working
(https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/228343).  The
issue with Ctrl+Alt+Tab seems to be that Compiz is using it for
something else: http://wiki.compiz-fusion.org/CommonKeyboardShortcuts.
I would definitely agree that Compiz's hotkey combinations get somewhat 
confusing and there's no ready tool to list all the combinations that
are currently active, nor a notification that the combination is already 
in use elsewhere.

Assuming that there is a scenario in which the default Compiz hotkeys
aren't going to change because non-a11y users are used to those hotkeys, would we want something where if Orca is detected to be in use, then use 
a different set of hotkeys than what is set up by default?   I would
presume that an Orca user has quite a few hotkeys of his/her own set up, 
and thus a more intuitive relationship between Orca and Compiz is
needed.
--
Bryen Yunashko
openSUSE Board Member
openSUSE-GNOME Team Member
GNOME-A11y Team Member

_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list gnome org
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list


_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list gnome org
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list



_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list gnome org
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]