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

[David Bolter <david bolter utoronto ca>]

Bill I agree we should involve key folks from JFC and GTK+.  Even if it 
isn't a discussion about what to keep, it would be great to have some 
help making the documentation clearer.

cheers,
David
Bill Haneman wrote:
> Aaron Leventhal wrote:
>   
> > In that case I'd say the buzzer is presentational just like the greyed 
> > out color.
> >
> > 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.
> >   
> >     
> STATE_ARMED, maybe.  But I couldn't, at this point, support deprecation 
> of STATE_SENSITIVE.
>
> Truth is, we are going about this (discussion) all wrong.  A few of us 
> can't safely just say "we don't understand this state, so we will get 
> rid of it".  The states were designed with intimate foreknowledge of the 
> GUI semantics, so in order to discuss this intelligently we would need 
> to involve fundamental GUI design folks in the conversation.  That 
> means, at a minimum, key folks in JFC and GTK+.
>
> I think, however, that we've already identified a sufficiently 
> meaningful semantic for SENSITIVE that we should leave it alone.
>
> Bill
>   
> > - Aaron
> >
> >
> > David Bolter wrote:
> >   
> >     
> > > I guess an underlying question is: do we need to expose all gui states 
> > > though a11y api?  It is tempting to say yes so that we don't limit 
> > > possibilities, but if there is a practical cost (e.g. IAccessible2 
> > > implementations, maintenance thereof) it seems murkier. We know one 
> > > common approach to API design is to provide only what is needed today 
> > > and let consumers of the API request additional API later.  That said, I 
> > > suppose it could still be argued that AT is more likely to use API if it 
> > > is in his/her face, but that doesn't seem to happen as often as we might 
> > > think. My rambling alarm is going off so I'll stop here.
> > >
> > > Bill would a use case of a button that is sensitive but not enabled be 
> > > for example a button that appears greyed out but still reacts to user 
> > > action on it in some way, say with a buzzer sound?  If it did anything 
> > > more useful... the GUI designer should probably be shot^D^D^D^D confronted.
> > >
> > > cheers,
> > > David
> > >
> > > Bill Haneman wrote:
> > >   
> > >     
> > >       
> > > > 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
> > > > >   
> > > > >     
> > > > >       
> > > > >         
> > > > >           
> > > > _______________________________________________
> > > > Gnome-accessibility-devel mailing list
> > > > Gnome-accessibility-devel gnome org
> > > > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
> > > >   
> > > >     
> > > >       
> > > >         
> > > _______________________________________________
> > > Gnome-accessibility-devel mailing list
> > > Gnome-accessibility-devel gnome org
> > > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
> > >
> > >   
> > >     
> > >       
> > _______________________________________________
> > Gnome-accessibility-devel mailing list
> > Gnome-accessibility-devel gnome org
> > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
> >   
> >     
>
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
>