After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 638378 - API change requested: text-selection-added, text-selection-removed, text-selection-updated
API change requested: text-selection-added, text-selection-removed, text-sele...
Product: atk
Classification: Platform
Component: atk
git master
Other Linux
: Normal normal
: ---
Assigned To: ATK maintainer(s)
ATK maintainer(s)
Depends on:
Blocks: 638537
Reported: 2010-12-30 22:18 UTC by Fernando Herrera
Modified: 2021-06-10 11:25 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Fernando Herrera 2010-12-30 22:18:37 UTC
Add 3 new signals for AtkText interface: text-selection-added, text-selection-removed, text-selection-updated including selection number, start and end offset params.

Rationale has been discussed here:

After these additions we should mark "text-selection-changed" as deprecated.
Comment 1 Li Yuan 2010-12-31 03:04:25 UTC
As we discussed on the list earlier, a text-selection-updated signal is equal to a combination of a text-selection-removed and a text-selection-added. What extra benefit do we get from this new signal?
Comment 2 Fernando Herrera 2010-12-31 04:00:04 UTC
Well, I can see two benefits of the update signal:
- Apps can coalesce 2 events:removed + added (less traffic over the wire)
- AT apps does not need to maintain state (what was removed, what was added) if they want to present the user a higher level event like text replaced/updated.
Comment 3 Li Yuan 2010-12-31 04:13:45 UTC
I guess this new signal means a lot code change of GAIL and other applications which implements their own accessibility (Evolution and Firefox).
Comment 4 Fernando Herrera 2010-12-31 04:23:03 UTC
Well, apps and toolkits can still fire removed/added combination of events but if the want, they could use the new "update". Of course that could be a worthless effort if it is not really very useful for AT apps. 

Joanie, any comments about having an update event?
Comment 5 Fernando Herrera 2011-01-17 12:49:57 UTC
Note: regarding update event, IA2 also includes it

probably to make things easier on the AT apps side and less event traffic.
Comment 6 André Klapper 2011-06-23 22:06:25 UTC
[Mass-reassigning open atk bug reports for better trackability as requested in .
If you have watched the previous assignee of this bug report as a workaround for actually getting notified of changes in atk bugs, you yourself will now have to add atk-maint@gnome.bugs to your watchlist at the bottom of to keep watching atk bug reports in GNOME Bugzilla.
Sorry for the noise: Feel free to filter for this comment in order to mass-delete the triggered bugmail.]
Comment 7 Joanmarie Diggs (IRC: joanie) 2011-12-19 18:32:33 UTC
(In reply to comment #4)
> Well, apps and toolkits can still fire removed/added combination of events but
> if the want, they could use the new "update". Of course that could be a
> worthless effort if it is not really very useful for AT apps. 
> Joanie, any comments about having an update event?

ATs like Orca need to know what became selected when it becomes selected, and what became unselected when it becomes unselected.

In the case where the selection changed and something got selected and something got unselected at the same time, I think that getting an event for each (i.e. 1 for added, 1 for removed) should suffice -- if it contained all the details needed for that AT to present the appropriate information to the user.

Is there something else you had in mind w.r.t. this updated event?
Comment 8 Alejandro Piñeiro Iglesias (IRC: infapi00) 2013-12-11 16:27:52 UTC
WebkigGTK2013 discussion:

As Joanmarie Diggs said on previous comment, the biggest features missing are:
  * Being able to know when you get something unselected and selected
  * Offsets for that information
  * Usually you want to expose to the user *both* events
  * We would like to include on the event also the selected/unselected text (something not mentioned on comment 0).

That make text-selection-update somewhat redundant, or event useless.

Additionally, take into account this enviroment:
  1. No selection. Cursor at position c
  2. User press shift and then right arrow key. So there are a new selection.
     (user don't stop to press shift)
  3. User right arrow again. So the selection changes.

Taking into account that the names proposed are text-selected-added and text-selection-removed, I automatically understood that the events expected are the following ones:
  2. text-selection-added (c, c+1)
  3. text-selection-removed (c, c+1)
     text-selection-added (c, c+2)

But that is not true. On 3 we are just updating the current selection, so just one event is expected. But emitting text-selection-added (c, c+2) sounds odd, as we still have just one selection.

Taking all that into account, we think that the final proposal would be:
  1. Reduce the proposal to just two signals
  2. Rename them to: text-selection-selected, text-selection-unselected
  3. Params needed: selection number, start and end offsets, selected/unselected string
Comment 9 André Klapper 2021-06-10 11:25:51 UTC
GNOME is going to shut down in favor of
As part of that, we are mass-closing older open tickets in
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version of atk, then please follow
and create a ticket at

Thank you for your understanding and your help.