GNOME Bugzilla – Bug 640440
Fine-tuning event listeners
Last modified: 2021-07-05 10:45:11 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.
Could ATs registering for events specify a predicate/condition which must be met? Examples: * 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)
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.
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
[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.]
[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!]
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, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/at-spi2-core/-/issues/ Thank you for your understanding and your help.