Re: [g-a-devel]Support for Color in ATK

[Peter Korn <korn sun com>]

Hi Draghi,

> > ...[discussion of use of color in widgets for pertinent information]
> > 
> > I think we can factor out the problem space into four main divisions, 
> > with several sub-divisions:
> >
> >  - Apps that use color for important info
> >     1. color is standard widget usage
> >         get from AccessibleState, AccessibleRole
> >
> >     2. color is set via foreground/background
> >         a. toolkit supports this -> get from AT SPI
> >         b. toolkit doesn't support this; nothing we can do
> >         c. also seek from app/widget via Accessible[State|Role]
> >
> >     3. color is really an icon (with AccessibleIcon being valid)
> >         foreground/background color doesn't matter, get via
> >         Accessible[State|Role] and also AccessibleIcon
> >
> >     4. color is rendered by app (custom widget?)
> >         a. app tries to be well behaved with Accessible[State|Role]
> >         b. need to talk with X display to get individual pixels!
> >
> > Is there any disagreement about the problem space factoring?
> 
> MP: So there is no "legal" GTK API to set the color of a standard widget
> different from the prefered fore/back colors?

That word "legal" is tricky, and has caused much churn in the Windows (and
Macintosh) accessibility worlds in the past.  In the Unix (and especially X)
world, you can't do anything without using API to do so.  The hardware (and
video display) is isolated from application code.  So, since the programmer is
using API calls to render color to a widget, it's "legal" right?  What it
clearly is, is counter to guidelines (be it generally GNOME programming
guidelines, user-interface guidelines, accessibility guidelines, whatever).

A key design goal for us API designers is to make following the guidelines
(whichever they are) as easy for developers to do as possible.  And of course,
many cats are out of many bags at this point (to do injustice to an
American/English saying) - we have to live with API conventions from GNOME 1.x
days.

So, we cannot prevent a programmer from rendering a widget with direct calls
to render specific things in specific colors; nor do we want to go down the
path of patching various rendering calls in order to figure out what's going
on (repeat five times: "we don't want to need an Off-Screen Model").  


So, we have to decide if the less-than-complete foreground/background color
info gives us enough of what we need for the cases above where Role/State
aren't sufficient; or whether we should instead focus our efforts on getting
developers to follow Role/State (and other) accessibility guidelines.

Perhaps in this instance the latter investment is the right one for now...



Peter