Re: [g-a-devel] Trying to understand STATE_SENSITIVE

[Willie Walker <William Walker Sun COM>]

I agree that choice of wording by GUI toolkit developers is sometimes
fraught with ambiguity and apparent conflict, especially when the same
words have different meaning across toolkits.  This does indeed cause
trouble with an API like AT-SPI that is trying to sit on top of multiple
toolkits. 

In GTK, the word "sensitive" appears to map to how the state SENSITIVE
is used in the AT-SPI:

http://www.pygtk.org/docs/pygtk/class-gtkwidget.html#method-gtkwidget--set-sensitive

"The set_sensitive() method sets the "sensitive" property of the widget
to the value specified by sensitive. If sensitive is True the widget
will be sensitive and the user can interact with it. An insensitive
widget appears "grayed out" and the user can't interact with it.
Insensitive widgets are known as "inactive", "disabled", or "ghosted" in
some other toolkits."

As such, I think the word 'sensitive' is being used appropriately in the
AT-SPI.  IMO, the main cause for confusion is that the use of the word
'enabled' in the AT-SPI and how its meaning there differs from how
enabled might be used in other toolkits.

Will

On Fri, 2007-01-19 at 14:49 +0000, Steve Lee wrote:
> Well I think you would need to give IA2 implementers *very* clear
> guidelines on how to use these states and how to map to the APIs and
> concepts that they use. For example my view that ENABLED means the
> user can interact (and implies a non-greyed visual style) comes from
> using EnableWindow() to control a controls ability to respond to the
> user via input device events (well mouse and keyboard). There's no
> concept of SENSITIVE there so I'd need to remember to add those
> semantics if required for IA2.
> 
> Can we think of concrete examples in GTK or other widget sets. Or are
> we trying to model something that may be theoretically possible but is
> never actually realised?
> 
> Steve
> 
> On 1/19/07, Willie Walker <William Walker sun com> wrote:
> > > > I don't believe any of the users of IA2 or ATK or using STATE_SENSITIVE
> > > > to mean anything other than STATE_ENABLED.
> > > > For one, no one understands it. Second, it's not actually useful because
> > > > if somethings greyed out it should not react to user input. As David
> > > > Bolter says, the UI designer should be shot if a greyed out widget
> > > > reacts to user input.
> > > >
> > > > I call to deprecate both STATE_SENSITIVE and STATE_ARMED.
> >
> > We use STATE_SENSITIVE in Orca.  The thing I understand is as follows,
> > though my understanding might be wrong because I'm not sure I've never
> > fully understood the relationship between ENABLED and SENSITIVE:
> >
> > SENSITIVE means the thing is not grayed out.  For example, you can press
> > a button.  It doesn't necessarily mean the application will do anything
> > when you press the button, though.
> >
> > ENABLED means that if the thing is SENSITIVE, manipulating it will
> > actually cause some sort of action in the application.  I'm not sure,
> > but I think it is possible to have an ENABLED component that is not
> > SENSITIVE.
> >
> > If this is correct, then SENSITIVE is more indicative of the visual GUI
> > state and ENABLED merely indicates non-visual application state.  From
> > an AT standpoint, I think SENSITIVE is the more practical state to look
> > for whereas ENABLED is mostly intellectually interesting.
> >
> > As such, if this were Sophie's choice, I'd choose to ditch ENABLED and
> > keep our dear SENSITIVE child.
> >
> > Will
> >
> >
> > _______________________________________________
> > Gnome-accessibility-devel mailing list
> > Gnome-accessibility-devel gnome org
> > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
> >
> 
>