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



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




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]