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

[Alexander Surkov <surkov alexander gmail com>]

Hi, Joanie. Answering inline.

On Fri, Dec 13, 2013 at 11:41 AM, Joanmarie Diggs <jdiggs 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