From: Joanmarie Diggs <[email protected]> Well, I already had a proposal in mind about event listeners (in a form of bug), but it was just specify that you can only listen to atk events, as right now you can connect to any event of type "event_type" [1], something that IMHO is somewhat diffuse. This is related to the bug related to a hypothetical AtkWindow [2], as right now, ATK implementors are required to allow to install listeners to Atk events + Window events.
Anyway, about your proposal: > 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 >From the ATK side, you connect to a specific application. The bridge require to install the global listener each time a application is registered. So I guess that from the implementation point of view, if required, that would be the place to start to do that, anyway ... > 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. > > I don't have any good ideas about how to implement fine-tuning for > event listeners. But since we're discussing Atk3/AT-SPI3 -- or > whatever Piñeiro is calling it ;-) ;-) -- I figured I'd toss it out > there for consideration. Well, taking into account that there is just one level of detail, the first straightforward solution would be add the role to the detail of the signal emitted (something like children-changed::add_atk_table). But in the same way would make more complex if the AT app what to connect to any ::add, without the role. BR [1] http://library.gnome.org/devel/atk/stable/AtkUtil.html#atk-add-global-event-listener [2] https://bugzilla.gnome.org/show_bug.cgi?id=638924 === API ([email protected]) _______________________________________________ gnome-accessibility-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
