Re: Setting window icons
- From: Peter Korn <korn sun com>
- To: gtk-devel-list gnome org
- Subject: Re: Setting window icons
- Date: Fri, 23 Feb 2001 08:30:36 -0800
Hi lupus,
> ...
>
> Speaking of accessibility APIs, a useful addition that could be
> used in gmag is something like this:
>
> gdk_set_interest_spot(gint x, gint y);
> /* should be per-screnn when ther is per-screen support in GDK */
>
> This can set a property in the root window that other applications like
> gmag may use to enlarge the part of the screen near the "intert" spot
> (currently it follows the mouse pointer).
> This is very useful to track the cursor position in text edit widgets
> or terminal emulation widgets: basically, whenever the cursor is moved
> the widget sets the interset spot to the screen coordinates of the cursor.
> This could be done automatically in the focus_in_event for many other
> widgets as well to enable following focus changes done with the keyboard.
> On focus out events the property should be unset, maybe calling:
>
> gdk_set_interest_spot(-1, -1);
The almost "standard" accessibility architecture these days (being that it's in
the two existing system-level accessibility APIs that exist - Microsoft's
Active Accessiblity and the Java Accessibility API) provides specific events
for focus tracking and caret movement. In addition, at least in the Java
platform case, for objects that don't formally take the focus but are
nontheless where keyboard input is going, like the flyweight components in the
Swing JTabbedPane and the table cells in JTable, additional events are exposed
for those. With this "standard" suite of events, screen magnifiers are able to
track pretty much everything interesting in applications.
What are the scenarios in which you would want a specific interest spot beyond
tracking caret and input location?
The one place where it occurs to me this might be important is with graphical
input methods for some of the more complex language character sets - e.g.
Cantonese. For some of these, it may be necessary to maintain the standard
notion of keyboard input focus on an application widget, yet a user who needs
magnification needs to have that magnification display the input method
dialog. For this situation, it might be very useful to have a special,
"out-of-bounds" way to convey to assistive technologies that the interesting
spot is in the input method dialog, and likely not where keyboard input focus
is...
Peter
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]