GNOME Bugzilla – Bug 639470
API change requested: Provide a means to "group" events based on trigger
Last modified: 2021-06-10 11:25:44 UTC
(This is a vaguely-worded request at the moment as I don't have a suggestion for how to accomplish what I'd like to see.) The problem is this: For any given user action, a bunch of associated events are generated. For instance, if the user selects a different mail folder in his/her desktop email client we will get one -- and often several -- events for: * The selection change related to the folder * The focus change related to the folder * The children change related to the list of messages * The selection change related to the list of messages * The focus change related to the list of messages * The name change related to each displayed label in the message preview * The text change related to the displaying of a different message in the preview And all of the above are inserted into a continuing stream (river, torrent) of other events from that same application and all the other applications running. Currently, events are not grouped with an action in any fashion. In addition, we cannot count on events coming in the same, easily-identifiable order. As a result ATs have to guess heuristically what triggered an event when trying to determine if an event is of relevance to the user. I don't know how best to "group" events, but it would be super if ATs could more definitely associate a given event (or event set) with its cause. Doing so would: * Take the guess work out of things (more reliable, consistent user experience) * Allow us to immediately toss aside events which are irrelevant (more performant user experience)
I think the challenge would be that the ATK implementor currently has no knowledge of what triggered an event--gail simply responds to signals that get sent whenever something in the UI changes, for instance. One simple way to add this would be to add an atk function to set a description and triggering object to be added to events, to be used in a toolkit like this: void gtk_button_clicked (GtkButton *button) { + AtkObject *accessible; + g_return_if_fail (GTK_IS_BUTTON (button)); + accessible = gtk_widget_get_accessible (button); + atk_set_event_group (accessible, "button clicked"); g_signal_emit (button, button_signals[CLICKED], 0); + atk_set_event_group (NULL, NULL); } However, I can see two potential issues with this: - We would need to define what to do if an event group is set twice (for instance, a user may press a key, which could trigger a group, and the key may cause a button to be clicked, which would also trigger a grouping, so should both groupings be presented, or does the second one override the first one while it is on the stack?) - More seriously, this scheme breaks down if particular UI changes are deferred to an idle handler rather than running synchronously with their trigger. It may be useful to determine how often this happens in practice.
ATK Hackfest Conclusion: * In general it seems that this bug would be hard to solve, or at least there is not a clear way to implement it. * So for the moment we would postpone this bug, until we find a different solution.
[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.]
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.