GNOME.org
 

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

+1

On 1/19/07, Aaron Leventhal <aaronlev moonset net> 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.

- 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




--
Steve Lee
www.oatsoft.org
www.schoolforge.org.uk
www.fullmeasure.co.uk
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]