|
API, What you describe below makes sense, and is how we do it in Java. No event listeners are inserted until an AT asks for them - in which case a bunch are added, including at least one more than the AT asks for (for tracking component add/remove from containers, since in Java/Swing events are peer-to-peer always). Regards, Peter On 2/22/2011 9:39 AM, Piñeiro wrote: Hi, probably this will lead to another bug under the umbrella of our "towards ATK 2.0" but [1], but I would to discuss a little it first. This idea appeared during the last events related to the integration of accessibility on the desktop, first Bastien Nocera and the gseetings and then Matthias Clases gail revamp. One of the issues mentioned is that on a perfect world, the accessibility framework (ie at-spi2) should be always running. That would avoid this "set on the accessibility requires to make a log out". Well, the main reason that prevents it, is that with the accessibility enabled (at-spi2 running), there are a overhead related, and in some cases (like bad use of gtktreeview-treeviewmodel) it could lead to some apps not usable at all. One comment of Bastien triggered the idea I have. He said that accessibility should be enabled as soon as Orca is started. And then I realized something. For a user that doesn't use any AT (Orca, or Caribou, etc), enabling the accessibility means that the apps registered on at-spi2 will start to sent events and other information at-spi2, but nobody is listening to at-spi2 from the other side, so that information is useless. So I'm proposing to debate if have sense to add an AT registration. So, it would be something like: a) Target apps register to at-spi2 (as it is done right now on adaptor_init, bridge.c::664) b) AT apps register to at-spi2 using an alternative (not existint yet) API. So, when apps register on at-spi2 on a), if there is any AT listening, the bridge will start to add the listeners to their events, and so on, as it is being done now. But if there isn't any AT listening, this registration will not be done, they will be just added to the register. If after some time any AT is registered, at-spi2 will ask to any app registered, to start to add the listeners and so on. In the same way it would be good to add a mechanism to remove the event emission on any app if the count of AT apps listening reaches zero. With this mechanism, at-spi2 can be running always, and apps always register to it, as it should be really safe to just add the apps to the register. As far as no AT tools is executed, that would just mean that the applications will be listed on the register, but there will not be any "hypothetical unstable interaction" with the at-spi2. Opinions, ideas? BR [1] https://bugzilla.gnome.org/show_bug.cgi?id=638537 === API (apinheiro igalia com) _______________________________________________ gnome-accessibility-devel mailing list gnome-accessibility-devel gnome org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel --
 Peter Korn | Accessibility Principal Phone: +1 650 506 9522 Oracle Corporate Architecture Group 500 Oracle Parkway | Redwood City, CA 94065 
Oracle is committed to developing practices and
products that help protect the environment
|