[Kde-accessibility] [g-a-devel] [Accessibility] Re: [Accessibility-atspi] D-Bus AT-SPI - The way forward

[Willie Walker]

Hi All:

I still need to catch up on all this mail.  It's all good stuff, and I'm 
excited to see intelligent and cooperative conversation going on.  In 
the meantime...

>> 	Having said that, it'd be great to build an understanding of what
>> people do synchronously during event emission & can't do elsewhere: to
>> add to the events themselves.
> 
> Yes! Please let us know, AT coders of the world!

I think there are a couple things to consider: 1) is there a need for an 
AT to process events synchronously, and 2) what other information can be 
sent in an event to avoid extra round tripping?

For the first question, Orca pretty much queue's all events and 
processes them on the gidle thread.  There are a few exceptions, but I'm 
not sure they require synchronous handling.

When it gets an event, a lot of what Orca does is:

o Determine which application the event came from.  This is important 
because Orca allows scripting per application.  Luckily, most toolkits 
support putting the application in the event, so we're pretty good with 
that.

o Look at the role of the event source.  Passing this along in the event 
would prevent a round trip.

o If Orca decides it needs to present something about the event source, 
we also typically look at the ancestry of the event source.  The main 
reason for this is to compare the ancestry of the current object with 
focus to the ancestry of the object that previously had focus so that 
Orca can present contextual changes in location.  I'm not sure sending a 
complete ancestry with every event would be desirable, though.

o The profiling work at 
http://live.gnome.org/GAP/AtSpiDbusInvestigation/OrcaExtraProfiling can 
also be used to give more insight.

Having said that, the main area where handling events synchronously is 
desired is with testing.  With this, we have a better chance at 
repeatable test results since the application's state will essentially 
block until we process the event in a synchronous manner.  A notable 
example of where asynchronous event handling can yield different results 
is typing in text areas.

Will