Re: Setting window icons



On 02/21/01 Peter Korn wrote:
> This is tough.  One big question still to be figured-out is how to best address
> magnification.  One approach is to ask apps to render themselves larger (e.g.
> 130%, 160%, 200%), which is ideal for a lot of folks who consider themselves
> not disabled, just "getting on in life" and needing things a big bigger.  This
> includes virtually all of the "baby boom" generation here in the U.S. who are
> finding themselves considering glasses for the first time.
> 
> For people with more serious visual impairments, rendering things 200% larger
> is nowhere near sufficient.  Commercial software magnification products
> typically will magnify from 2x to 16x, so one pixel becomes 4 or 9 or 16 or...
> (and many of these products use "font" smoothing algorythms so the pixels
> aren't so blocky) - see Windows 98/2000 "Magnifier", or Macintosh CloseView for
> some examples.  For these users, they won't be that interested in applications
> re-rendering themselves - instead they will rely on their deskto/system-wide
> magnification product.

gmag can be used to have, for example, the part of the screen near the pointer
enlarged continuously in a window (and this window could be as large
as half the display, for example: this makes 8x magnification still practical).
I recently changed it to use gdkpixbuf instead of imlib for
scaling the images: this allows the use of better scaling algorithms
at the cost of highter CPU usage. GDK_INTERP_BILINEAR works fine, though
it may need a sharpen pass applyed after it.
gmag can also enhance the contrast of the enlarged image (this is needed
for some visually impaired person).

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);

Comments welcome.

lupus

-- 
-----------------------------------------------------------------
lupus debian org                                     debian/rules
lupus ximian com                             Monkeys do it better





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