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 [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
