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 640440 - Fine-tuning event listeners
Fine-tuning event listeners
Product: at-spi
Classification: Platform
Component: at-spi2-core
Other All
: Normal normal
: ---
Assigned To: At-spi maintainer(s)
At-spi maintainer(s)
Depends on:
Blocks: 638537
Reported: 2011-01-24 16:49 UTC by Joanmarie Diggs (IRC: joanie)
Modified: 2021-07-05 10:45 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Joanmarie Diggs (IRC: joanie) 2011-01-24 16:49:12 UTC
As I understand it, when an AT registers a listener for a given AT-SPI event, there is no way to specify things like:

* The object role(s) the AT cares about w.r.t. that event type
* The app(s)/toolkit(s) the AT cares about w.r.t. that event type

For instance, if Orca cares about object:children-changed events from OOo for tables, Orca is then forced to listen to -- and subsequently filter out -- all object:children-changed events that any running accessible app happens to emit for any type of accessible.

It would be helpful to have a means to fine-tune event listeners so that ATs are only receiving those events (about those object roles and from those sources) they actually care about.
Comment 1 Joanmarie Diggs (IRC: joanie) 2011-04-19 21:58:23 UTC
Could ATs registering for events specify a predicate/condition which must be met? 


* App only cares about object:state-changed:focused if event.detail1 == 1

* App only cares about object:text-changed events if the parent window has STATE_ACTIVE

And, of course, would doing so be worthwhile? (i.e. how much would we save by preventing certain events from being communicated)
Comment 2 Mike Gorse 2011-04-27 20:57:35 UTC
There are a couple of ways of going about this:

(1) add parameters to registerEventListener to optionally specify a toolkit
and a set of roles, passing this information on to applications, or

(2) implementing a more sophisticated system for specifying the events
that should be passed on (would XPath and/or JSON be helpful?); I think that
we would need this to be able to filter on things like whether an object's
parent's state set contains STATE_ACTIVE.

(2) would be significantly more work.  Would it be worth doing?  However,
bug 640949 is somewhat similar; we might want a flexible way to specify the
data that we want included with events, so it seems worth investigating
whether there are libraries that could help with this on the application side.
Comment 3 Alejandro Piñeiro Iglesias (IRC: infapi00) 2011-05-11 09:48:55 UTC
Some ATK 2011 Hackfest conclusion: 

  * It is not clear if a general way to specify how to filter the events worths the effort.
  * It seems that any kind of filtering would be useful to ATs
  * So next step would be define the most useful filtering parameter
  * Also it seems that this change doesn't require further support on ATK, so we are going to move it to at-spi
Comment 4 André Klapper 2012-02-26 10:41:40 UTC
[Resetting QA Contact to newly introduced "at-spi-maint@gnome.bugs". 
Reason: So far it was impossible to watch changes in at-spi bug reports without following all the specific persons (Li Yuan, Bill Haneman, Jeff Wai, ...) and also their activity outside of at-spi reports.

IMPORTANT: Anyone interested in following all bug activity (including all maintainers) must watch the "at-spi-maint@gnome.bugs" dummy user by adding it to the 'Users to watch' list under Preferences->Email preferences. This is also the default procedure nowadays in GNOME when setting up new products.]
Comment 5 André Klapper 2013-08-14 10:04:32 UTC
[Mass-resetting default assignee, see bug 705890. Please reclaim this bug report by setting the assignee to yourself if you still plan to work on this. Thanks!]
Comment 6 GNOME Infrastructure Team 2021-07-05 10:45:11 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, then please follow
and create a new ticket at

Thank you for your understanding and your help.