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 639470 - API change requested: Provide a means to "group" events based on trigger
API change requested: Provide a means to "group" events based on trigger
Product: atk
Classification: Platform
Component: atk
Other All
: Normal enhancement
: ---
Assigned To: ATK maintainer(s)
ATK maintainer(s)
Depends on:
Blocks: 638537
Reported: 2011-01-13 21:56 UTC by Joanmarie Diggs (IRC: joanie)
Modified: 2021-06-10 11:25 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Joanmarie Diggs (IRC: joanie) 2011-01-13 21:56:54 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)
Comment 1 Mike Gorse 2011-04-27 20:21:36 UTC
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:

 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.
Comment 2 Alejandro Piñeiro Iglesias (IRC: infapi00) 2011-05-11 09:54:16 UTC
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.
Comment 3 André Klapper 2011-06-23 22:06:18 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 4 André Klapper 2021-06-10 11:25:44 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.