Re: [g-a-devel] gnome-mag, full screen magnication and composite



Hi Carlos,

Excerpting from the end of your e-mail:
Because we must implement a composite manager or embbed magnifier logic
in window-managers. The first will only have good performance in good
computers with good video cards. This is not a big problem, since the
prices are lowering more and more, but we still with a glue code in the
application that can be avoided. The later sounds very terrible to me,
since magnifiers and window-managers are to distinct things. I, like a
magnifier developer don't want to worry in my code with some question
related about window-manager, and I think that the vice-versa is true.
Moreover, a window-manager is a policy while, for me and I think to you
too, the magnifier service is a mechanism.

Magnifiers and Window Managers have been distinct things up until now. But I am not convinced that is necessarily a good thing.

I believe the fundamental purpose of magnification software is to enable someone with any of a variety of visual impairments to be able to:

a. see what is on the screen
b. track specific regions on the screen - either mouse interactions, text caret, keyboard focus, OR other things that may be updating (e.g. multiple "zoom regions", tracking changes to a formula bar in a spreadsheet)
c. find things that they want to interact with
d. otherwise use the desktop & computer to accomplish the same sorts of things as everyone else

Looking at these tasks, basic magnification can accomplish (a). Tracking things (for task (b)) needs the magnifier to be driven by things like at-spi, and a lot of logic to do this is in Gnopernicus & Orca (with more coming over time). But when it comes to (c), there are things that would be nice to do that we haven't really gotten to yet, on any platform. Products like ZoomText and inLARGE had modes to toggle back and forth between unmagnified & magnified views (with a heavy 'border lens' showing where the user was relative to the entire desktop). Gnopernicus has a 'proportional' mode that uses the mouse location on the magnified view to indicate where the mouse is on the entire desktop. But these are really somewhat limited tools.

However, some of the things that COMPOSITE gives us, and some of the features in the new window managers, suggest some very interesting new opportunities for helping users find things. For example, why not have the magnifier zoom a specific window to the entire screen? Or zoom a pair of windows to sharing the entire magnified screen? Or overlay some notification information to a portion of an otherwise magnified screen? Such tasks are essentially "window manager" tasks, yet when combined with magnification they can offer some interesting potential improvements for efficiency and productivity for users with vision impairments - rather than relying on a magnifier to do the magnification, and a window manager to hopefully do some of these sorts of things, and try to get the magnifier to try to optimize the end-user result.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

regards,

Bill

If we use composite in gnome-mag we must have a window-manager like code
in it to manage windows that come and goes, windows overlap, so we must
track a lot of events and use clip lists, I don't know if the server can
generate clip list to us, to render only the window parts the will be
showed in the screen. I think that we can make a good job on this to
maintaim the magnifier responsive in the case that the user don't have a
good video card, but we still with a memory problem, because with
composite each window is maintained in off-screen memory. This is not a
big problem to new video cards, but I think that we could, and must do
this work in older hardware.

Another solution that is hitting my head is that we could change a bit
the server, so we put the magnifier window in top of all others,
something like the OverlayWindow in composite, and paint the contents of
all windows below it in a pixmap with the same properties of the root
window using the same algorithm that is already used in the server.

I think that this second solution is better, but maybe there are reasons
to doesn't try it there I don't realize here. I'm very motivated to try
this, so if there isn't any good arguments to forget this possibility I
will start to play.

Thanks,




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]