Re: [g-a-devel] API deprecations?

[Aaron Leventhal <aaronlev moonset net>]

Hi Bill,

Thank you -- this helps IMO. Couple of questions:

* What is the potential use case for STATE_ARMED?
* It would go a long way if we could clear out any recursive definitions 
of states, and fix any inconsistencies in the API docs for ATK and AT-SPI.
By recursive definitions I mean things like "ATK_STATE_TRANSIENT should 
be used for objects which are transient". Often times it's the most 
difficult states that are under-defined in the docs. It's not obvious 
what TRANSIENT means and some of the other states mean precisely enough, 
and ultimately it would be helpful to have clarity on what their 
intended uses are from the AT and app side.

- Aaron

Bill Haneman wrote:
> Hi;
>
> Recently Aaron pointed out several points where the API docs were 
> lacking, and where we had what appeared to be non-useful or 
> near-redundant API.
>
> If I recall correctly, the observations/proposals from Aaron included 
> the following:
>
> 1. STATE_ENABLED and STATE_SENSITIVE - are they both useful, and what is 
> the difference?
> 2. STATE_ARMED : OK, we agree what it means, but is it useful?
> 3. AtkText:getText[At, Before, After]Offset: deprecate 
> BOUNDARY_TYPE_SENTENCE as something that the AT client should do.
>
> #1: I think the majority conclusion has been that while STATE_ENABLED 
> and STATE_SENSITIVE might be theoretically different, these are 
> toolkit-centric subtleties and from the user point of view they are, or 
> at least ought to be, equivalent.  STATE_INCONSISTENT can be used to 
> modify the meaning of STATE_SENSITIVE, if we need to indicate when 
> objects react to user input but are nonetheless out-of-sync with the 
> value or component which they potentially control. 
>
> Even though I think historically we must have had a good reason for 
> making ENABLED and SENSITIVE different, I don't see any current value in 
> keeping them both, especially since the definitions are so 
> underspecified.  So I support deprecating STATE_ENABLED in favor of 
> STATE_SENSITIVE, and tying the two together in the atk-bridge (just to 
> keep legacy AT clients working as before).
>
> #2: I think there is a potential use for STATE_ARMED although it is very 
> limited.  We probably ought to retain it.
>
> #3: AtkTextgetText<boundary> : I support Aaron's proposal to deprecate 
> BOUNDARY_TYPE_SENTENCE and keep the other boundary types, unless someone 
> in the orca or LSR team wants to retain it.
>
> I hope it's helpful for me to write up my thoughts on this.  If readers 
> agree then we can go ahead.
>
> Best regards
>
> Bill
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
>
>