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 >>>>> [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 >> >> > > _______________________________________________ > 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
