Hi, Joanie. Answering inline.
On Fri, Dec 13, 2013 at 11:41 AM, Joanmarie Diggs <jdi...@igalia.com> wrote:
> 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.
>
Said above can be applied to wrong value which is exposed as invalid state
but nevertheless it's a state. So I don't see a semantical contradiction
here. If the value is optimal then control is in optimal state.
> 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.
>
Right. Not sure how missing information bites though.
> 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?
>
States approach isn't scalable, right, but probably we don't need scalable
API here. I don't really have any other example where it can be reused. I
suspsect that HTML5 meter will be unique element of this sort.
> 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?
Maybe 10 minutes vs 30 minutes so not big deal.
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.
>
is that ATK requirement? It seems like AT would need value change event
only (state change events would be duping in that case).
> 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?
>
IA2 development is much slower than ATK. So I feel skeptical about new
interface. We could go with object attributes (IA2 allows to have non
string type attributes). Jamie suggested states approach. So basically I
went here to figure out what guys you think. Having less diversity in APIs
is highly appreciated by me :) but in any case I think Firefox can
implement both versions if ATK gets different from IA2.
Also, what would the human-consumable name of these "states" be?
>
a good question, probably OPTIMAL, SUBOPTIMAL and NOT_OPTIMAL or
SUBSUBOPTIMAL if it makes sense.
Thank you.
Alex.
> --joanie and alejandro
>
_______________________________________________
gnome-accessibility-devel mailing list
gnome-accessibility-devel@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
