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 _______________________________________________ Gnome-accessibility-devel mailing list Gnome-accessibility-devel@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
