On Fri, Dec 13, 2013 at 01:41:30PM -0500, Alexander Surkov wrote:
> 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.
maybe not contradiction just trying to stuff too much data into too
small space.
> 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.
seems like it would be nice to provide as much info as possible 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.
yeah, both state approach and value one seem like one off things for
this, but value interface having text value property is probably
generally useful.
> 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).
Well, if the state changes I'd say we should fire state change event.
Trev
> 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
_______________________________________________
gnome-accessibility-devel mailing list
gnome-accessibility-devel@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
