Willie et al, I was just thinking before actually reading this emai to write you (Willie) so we could restart this discussion so I can write a nice proposal for my next Mozilla grant proposal so I can possibly start working on this by next month or so.
I will start writing a document and creating a gnome live page for this work if this sounds ok with you. ariel On 8/28/07, Willie Walker <[EMAIL PROTECTED]> wrote: > > 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 > [EMAIL PROTECTED] > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list >
_______________________________________________ Gnome-accessibility-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
