Community
Participate
Working Groups
The native widgets on Linux (RHEL 5 or FC5) that have selectable children already expose the Selection interface. (See http://developer.gnome.org/doc/API/2.0/atk/AtkSelection.html.) Custom widget authors (including Draw2d and GMF authors) need the ability to expose selected children to native assitive technologies (like a screen reader). I suggest adding a new AccessibleSelectionListener to the org.eclipse.swt.accessibility package to allow custom widget authors the ability to expose the rich AtkSelection interface. Note that this selection is distinguished from text selection by exposing selection of (usually lighweight) accessible children instead of a subset of the object's content. The mechanism to implement this functionality on Windows will be added soon.
Just curious - the current API allows the parent object to send accessible.selectionChanged() ...which of course leaves it up to the screen reader to find out what changed (because no details are given). I could see that this might be inefficient. The question is: is there any information that the screen reader just cannot get in this scenario?
(In reply to comment #1) Yes, this is inefficient. But on Windows it may not matter since the screen reader runs in-process. The trade-off is between always including the changed information versus storing old and comparing to new selection only when needed. Since the screen reader may ignore the event, or only be interested in the current selection, there is no compelling argument to include the change information on Windows. But on Linux the screen reader is required to run in another process. And as a result, ATK accessibility events include old and new values to minimize the number of cross-process calls. When the event includes no change information, the screen reader has to store "old state" information for comparison to the "current state" to determine the nature of a change. Otherwise the screen reader has no way of determining (and presenting) a non-focused (programmatic) change of selection.
Thanks, Larry. Next question - forgive me for not being up-to-date on Linux screen readers - is there a plan in progress to allow screen readers and other AT's to run in-process? Again, just curious.
(In reply to comment #3) There is no plan to allow Linux screen readers to run in-process. But there is a plan to require Windows screen readers to run out of process. Microsoft calls it "managed applications" made accessible through UI Automation. Requiring the AT to run out of process is the future on all platforms due to security requirements.
Thanks, Larry. Carolyn
Since eclipse 3.6, apps can inform AT that the selection has changed by sending EVENT_SELECTION_CHANGED event. On the text side, AT can now receive the EVENT_TEXT_SELECTION_CHANGED event, and they can ask getSelectionRange, and text controls can have multiple selections, and AT (such as speech recognition systems) can even modify text selection(s) and manipulate the caret. AT can also query and modify selection in Tables by row/column or cell. AT can still call getSelection. We have no plans at this time to add the generic selection interface. I will leave this bug open in the event that we ever do decide to add it.
Removing target milestone.
Closing. If there is a real need for selection interface, please open a new bug with specifics.
