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



Peter,

You bring up a great point!  I have always felt that learning/cognitive AT
software has been underdeveloped.  Programs similar to Kurzweil/WYNN are
unavailable for Linux.  A well thought out GUI wrapping a overlay API, Orca,
OCR/Scan, learning tools(dictionary, note taker, etc) would be very
impressive. 

The majority users at our campus use Zoomtext for the auditory and visual
focus elements, not for magnification.  Reading web articles, scanned books,
and pdf files with Zoomtext is a great feature of Zoomtext.  AppReader and
DocReader are great accessibility tools for a diverse group of users.

The work done with gnome-mag and eZoom has really opened some eye at our AT
center.  Specifically, separate zooming windows on separate monitors has
received some great applause from myself and other low vision users.

Thanks,

Jason Grieves

>Another use case is for magnification to overlay various things (in 
>perhaps that same alpha-blended layer) for a different kind of visual 
>highlighting - e.g. to better highlight the text caret or focused 
>control (see ZoomText 8 and 9 on Windows for some nice examples of 
>this).  Down the road if something like Orca is reading a document, this 
>kind of functionality would be very useful for cognitive impairments 
>that affect reading

-----Original Message-----
From: gnome-accessibility-list-bounces gnome org
[mailto:gnome-accessibility-list-bounces gnome org] On Behalf Of Peter Korn
Sent: Tuesday, August 28, 2007 3:41 PM
To: Carlos Eduardo Rodrigues Diógenes
Cc: gnome-accessibility-devel gnome org; gnome-accessibility-list gnome org
Subject: Re: D-BUS based magnification API

Hi Carlos,

There are several additional AT uses I've been part of discussions on 
that might inform your new API. 

One is for something like an on-screen scanning keyboard to scan in 
place -> to highlight regions of the screen, regions of a window, in 
order to allow a user who can only press a single button/switch to 
successively narrow down which part of the UI they want to interact 
with.  E.g. first you cycle through all top-level frames; then through 
main items in a window (menu bar, toolbar, content region), then through 
items (toolbar items).  To properly highlight these regions, an AT would 
really like to be able to draw to a final, screen-wide, alpha blending 
layer that only AT could own.  Also, for the cycling of top-level 
frames, this AT would really like to be able to make requests of the 
window manager for things like that.

Another use case is for magnification to overlay various things (in 
perhaps that same alpha-blended layer) for a different kind of visual 
highlighting - e.g. to better highlight the text caret or focused 
control (see ZoomText 8 and 9 on Windows for some nice examples of 
this).  Down the road if something like Orca is reading a document, this 
kind of functionality would be very useful for cognitive impairments 
that affect reading -> to alpha-blend something like a light yellow 
highlight over each sentence as it is being spoken.  If magnification is 
also taking place, you'd want the magnifier to appropriately magnify 
this layer as well.  And perhaps you have the layer at full (magnified) 
resolution, so you wouldn't need to magnify it and thus it would be 
jaggy-free.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

> Hi,
>
> I would like to create a D-BUS based magnification API, but since some
> radical changes where introduced in the desktop due the X composite
> extension, and I'm not involved with the applications that use
> gnome-mag API, I would like to hear the community before present
> something.
>
> 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.
>
> I'm thinking in implement this new API inside the metacity compositor,
> so I don't think that the possibility to set the source and target
> display is something that must be addressed by this new API. If the
> user still want to use this feature, gnome-mag can be used.
>
> I also would like to now if someone have interest in the concept of an
> 'unmanaged' zoom region; that is, a zoom region that have content
> defined by the application using the API. Although this is something
> that is in gnome-mag API, I don't know if this is working. Maybe we
> can remove this from the new API.
>
> 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.
>
> 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 also would like to hear comments from users and ATs developers what
> are the features that they miss in free software/open source
> magnifiers.
>
> Best regards,
> Carlos.
>
> [1]
http://svn.gnome.org/viewcvs/gnome-mag/trunk/idl/GNOME_Magnifier.idl?view=ma
rkup
> [2]
http://mail.gnome.org/archives/gnome-accessibility-devel/2007-August/msg0001
4.html
> _______________________________________________
> gnome-accessibility-list mailing list
> gnome-accessibility-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
>   

_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list gnome org
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list




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