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.


Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.


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

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

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

Best regards,

gnome-accessibility-list mailing list
gnome-accessibility-list gnome org

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