+1 On 1/19/07, Aaron Leventhal <[EMAIL PROTECTED]> 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 > >>> [email protected] > >>> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel > >>> > >>> > >>> > >> _______________________________________________ > >> Gnome-accessibility-devel mailing list > >> [email protected] > >> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel > >> > >> > > > > _______________________________________________ > > Gnome-accessibility-devel mailing list > > [email protected] > > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel > > > > > _______________________________________________ > Gnome-accessibility-devel mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel >
-- Steve Lee www.oatsoft.org www.schoolforge.org.uk www.fullmeasure.co.uk _______________________________________________ Gnome-accessibility-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
