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

[Rob Taylor <rob taylor codethink co uk>]

Thanks Willie, this is pretty helpful :)

Willie Walker wrote:
> 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.

It's worth noting that inherently in dbus we can tell which application
a message came from (as identified by its unique bus name). In a
dbusified AT-SPI it may well be worth using this unique bus name as an
'application identifier'.

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

*nod* this would probably be a great optimisation :)

> 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.

That's interesting. One option that we need to consider is expressing
the object hierarchy in the dbus object path (which is structured
hierarchically already). Then an application could immediately tell the
ancestry by looking at the origin of the signal (all dbus signals
contain an object path for the originator of the signal).

> 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.

Could you go into a bit more detail on this example?

Thanks,
Rob

> Will


-- 
Rob Taylor, Codethink Ltd. -  http://codethink.co.uk