[g-a-devel] API deprecations?

[Bill Haneman <Bill Haneman Sun COM>]

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