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

[Bill Haneman <Bill Haneman Sun COM>]

Aaron Leventhal wrote:
> STATE_SENSITIVE doesn't make sense to me. It think it should either be 
> deprecated or the ATK/AT-SPI docs need to be clear. Is STATE_SENSITIVE 
> doing something we can't do with other states such as ENABLED and 
> INDETERMINATE?
Yes.  I attempted to explain this in the API docs for AT-SPI.
>  It seems like everything in Mozilla that's enabled should 
> also be sensitive? Not filing a bug because I'm not sure what to 
> recommend in the bug.
>
> ATK:
> ATK_STATE_SENSITIVE   Indicates this object is sensitive
> -> Self-referential sentence
> ATK_STATE_ENABLED   Indicates that this object is enabled. An 
> inconsistent GtkToggleButton is an example of an object which is 
> sensitive but not enabled.
> -> What's an inconsistent button? Why isn't it ENABLED and INDETERMINATE?
>
> AT-SPI:
> STATE_SENSITIVE   Indicates this object is sensitive, e.g. to user 
> interaction. STATE_SENSITIVE usually accompanies STATE_ENABLED for 
> user-actionable controls, but may be found in the absence of 
> STATE_ENABLED if the current visible state of the control is 
> "disconnected" from the application state. In such cases, direct user 
> interaction can often result in the object gaining STATE_SENSITIVE, for 
> instance if a user makes an explicit selection using an object whose 
> current state is ambiguous or undefined.
> -> I don't understand this
>   
'ENABLED' is usually not appropriate for GUI items that don't currently 
reflect the application state (i.e. are not 'wired in' to the app 
state), but such buttons can nonetheless react to user interaction (in 
which case they are still SENSITIVE).

For instance, if a 'greyed out' button changes to 'not greyed out' when 
you click on it or otherwise interact with it (which can happen in some 
edge cases), it is SENSITIVE because it reacts to user interaction, but 
it still started out 'grey' to indicate that it was not in sync with the 
application state prior to user action.

You are right that this is similar to what can happen with INDETERMINATE 
state, but not quite the same.
> STATE_ENABLED   Indicates that this object is enabled, i.e. that it 
> currently reflects some application state. Objects that are "greyed out" 
> may lack this state, and may lack the STATE_SENSITIVE if direct user 
> interaction cannot cause them to acquire STATE_ENABLED.
> -> I don't understand this
>
> Also gok/gok-keyboard.c:
> (gok_style_if_enabled): Check for SPI_STATE_SENSITIVE
> instead of SPI_STATE_ENABLED; this is because SENSITIVE
> has the semantics we really want, ENABLED can be false for
> a few actionable elements such as radiobuttons which are in
> the "indeterminate" state (i.e. no radiobutton in the group is
> toggled yet). Fix for bug #136877.
>
> -> I don't see why radio buttons aren't considered enabled in this state.
> -> Is INDETERMINATE expected on radio groups with no no checked radio 
> button?
>   
Not sure about this last question.  I think "no" since states like this 
aren't usually applied to groups, only to individual actionable 
components (and the individual radio buttons are probably not, in this 
case, indeterminate).

Agreed that this is a confusing area, but the semantics of GUI 
components are like that (in fact GUI component semantics are where most 
of these states are borrowed from - for instance read the Java JFC docs 
regarding components - GTK+ is similar too).

Bill
> - Aaron
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
>