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 _______________________________________________ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
