GNOME Bugzilla – Bug 638378
API change requested: text-selection-added, text-selection-removed, text-selection-updated
Last modified: 2021-06-10 11:25:51 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: http://mail.gnome.org/archives/gnome-accessibility-devel/2010-December/msg00007.html After these additions we should mark "text-selection-changed" as deprecated.
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?
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.
I guess this new signal means a lot code change of GAIL and other applications which implements their own accessibility (Evolution and Firefox).
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?
Note: regarding update event, IA2 also includes it http://dev.linuxfoundation.org/~ptbrunet/ia2/docs/html/_accessible_event_i_d_8idl.html#e26846b6d521727ab696d20c3f43c0b5 probably to make things easier on the AT apps side and less event traffic.
[Mass-reassigning open atk bug reports for better trackability as requested in https://bugzilla.gnome.org/show_bug.cgi?id=653179 . PLEASE NOTE: 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 https://bugzilla.gnome.org/userprefs.cgi?tab=email 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.]
(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?
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
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org 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 https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a ticket at https://gitlab.gnome.org/GNOME/atk/-/issues/ Thank you for your understanding and your help.