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

[Steve Lee]

I'm just adding my 2 cents from what I've been finding as a AT-SPI
nube using pyatspi for Jambu. I started off not thinking much about
interprocess issues and sort of just assumed the event handler was
async and I could do what I like in it. I got a rude awakening when
changes I made affected behaviour in subtle or random ways, plus I was
getting almost continuous desktop lockups (and forget using a
debugger).

> > As its stands I've yet to see a real-world usecase for pumping signals
> > faster than user input, though of course, we've tested this case ;). In
> > AT-SPI the event reception is dwarfed by synchronous calls to handle an
> > event, usually to the process that sent the event, so starvation isn't
> > an issue here.

Populating the file open dialog in gedit in a large directory
generates plenty of event traffic.

Also I find for simple actions that several of the events you could
expect to occur for completeness are just not there. If this is
addressed it may well result in increased event traffic for simple
application state changes.

>         Of course - we 'solved' this problem in at-spi by going synchronous for
> all events; but ... ;-) that's not such a wonderful solution either.

Indeed. For example if you want to print events to see what's going on
you need to put in a queue to handle it asynch. I've actually now
decoupled most processing this way at the risk of occasional timing
issues due to the latency . At least we can assume reads/writes will
not be pre-empted (I hope). So the onus is on the AT writer to sort it
out.

-- 
Steve Lee
--
Jambu - Alternative Access to Computers
www.fullmeasure.co.uk