Re: [g-a-devel] new states for meter element

[Joanmarie Diggs <jdiggs igalia com>]

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