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

[Peter Korn <Peter Korn Sun COM>]

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,
> > >