On 12/12/2013 04:12 PM, Alexander Surkov wrote: > I'm ok with AtkValue extension, it makes sense if Orca wants complete > information about the control.
Exactly how Orca is going to provide this information is something I am still considering. But potentially, yes, Orca is going to want this information. The problem we have with states are the following: 1. States apply to the widget itself; the low, high, and optimum are not states that apply to the meter *widget*. They describe the current value. 2. A given value falls somewhere within a subrange. Something can be "a tiny bit {low,high}", "smackdab in the middle of {low,high}" or "really, really {low,high}. If we make these things AtkStates, we lose the "how much" with respect to those attributes. 3. This solution does not seem like it will scale. What happens if, down the road, the meter (or some other value-reflecting widget) has more than these (low, high, sub-optimal) ranges? > That's why states were suggested > originally since they would be descriptive for visual part and don't > require much work as opposed to value interface. Is it that much more work? Meters will need to have an associated AtkValue implementation in which the minimum, maximum, and current values can be obtained. So we're asking for implementors to provide the high, low, and optimum values in addition to the values already being provided. Also, meters will need to emit a value-changed event. If you go the state route, meters will also need to emit a state-changed event. Whether or not the ordering of these events will matter is something I'd have to give some more thought to. Regardless, the "more work" issue surprised me. On a related note, since IA2 is presumably having to deal with these same issues, have they made a decision on the new API yet? Also, what would the human-consumable name of these "states" be? --joanie and alejandro _______________________________________________ gnome-accessibility-devel mailing list gnome-accessibility-devel@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel