Re: [g-a-devel] D-BUS based magnification API

[Willie Walker <William Walker Sun COM>]

Hi Carlos:

This is a very timely discussion to have since there are a bunch of
thoughts on many people's minds right now.  These include the following:

* Eliminating the Bonobo dependency from accessibility stuff in GNOME.  
  Note that this doesn't necessarily equate to eliminating CORBA.

* Understanding where the masses are going with respect the 
  composite extension manager.  Is it metacity, compiz, something 
  else?  Where/how does gnome-mag fit in this new world?

> First, I thought in develop a one-to-one map between the actual
> gnome-mag API[1] and this new API, but I think that some things don't
> need to go to the new API.

One of the philosophies behind the gnome-mag API seems to be that the
thing driving the magnifier also provides the configuration GUI for it.
Thus, Orca provides a whole page dedicated to setting up configuration
options for the magnifier, leaving lots of room for improvement.

An alternative approach might be that the magnifier acts as its own
entity, listening for AT-SPI events and making its own autonomous
decisions about what to bring into view and how to bring it into view.
With this, the magnifier would provide its own configuration GUI,
allowing it to be as rich as it would like.  It would also help provide
a nice division of labor among assistive technology developers.

At the same time, the magnifier should be able to listen for
hints/requests from other applications such as Orca.  These hints might
be as simple as suggestions for what area of the display to magnify (and
perhaps why).  For example, Orca might provide hints about what it is
presenting as part of the SayAll and flat review operations: what is it
presenting (e.g., where on the screen, maybe even a cross-process
reference to an accessible) and why is it presenting this information
(e.g., speaking a line, word, character)?  The magnifier could then
bring things into view accordingly, doing things such as centering the
region if the magnifier preferences dictate this.

To take this a step further and look at it from a different point of
view, one might consider an API for a screen reader to broadcast what it
is currently doing.  If a magnifier were to listen for these things, it
could add them to its other sources of information (e.g., AT-SPI events,
mouse movement events, etc.) to make intelligent decisions about what to
do.  If a different assistive technology (e.g., something that
selectively dims areas of the screen or highlights text or whatever)
listened for these things, it could also react in its own way.  With
this approach, a screen reader need not write support for all existing
and future assistive technologies it might need to interact with.
Instead, other assistive technologies can add screen reader information
to their other sources of information and makes their own decisions.

> Today the mouse tracking mode is managed by clients applications, but
> appear that the AT developers would like to see this feature moved
> inside the magnifier. I don't see problems with this, but I think that
> we must also maintaim the possibility to also control the mouse
> tracking logic by external ATs, since these applications track more
> information about the environment and can alter this mouse tracking
> logic.

Agreed.  I would like to eliminate the need for Orca to have to listen
for mouse events from the AT-SPI via CORBA, only to turn around and send
a filtered/translated form off to gnome-mag over CORBA.  Instead, I
would like to see gnome-mag listen for mouse events directly and update
zoomer information accordingly.  Right now, we see four mouse tracking
styles - none, centered, proportional, and push.  They are relatively
simple to implement and getting them in gnome-mag would be a big plus.

> I also read some stuff about the eZoom plugin for compiz-fusion and
> some of it's API [2]. I would like to know if someone of they must be
> in this new API? I saw some interesting comments about users that
> would like that what they are typing be in the center of the
> magnification window. This doesn't appear to be difficult to use in
> the actual gnome-mag API. This just appear to be the same logic to
> track the mouse in the center of the magnifier window.

I think the best thing to do is take a step back and involve end users
in the design.  We need to hear what they want from a magnifier, how
they use it on a daily basis, what they expect when using it with other
assitive technologies, etc.  I'm not sure I've seen a lot of this. 

Are you coming to GNOME Boston 2007?  Magnification is one of the
critical things we want to talk about for the accessibility summit.

Will