[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-accessibility
Subject:    Re: [Kde-accessibility] [g-a-devel] [Accessibility] Re:
From:       David Bolter <dtb () gnome ! org>
Date:       2007-12-14 18:35:05
Message-ID: 4762CCD9.7030403 () gnome ! org
[Download RAW message or body]

Steve Lee wrote:
> 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.
>
>   
Yeah. We use a queue in GOK which we process in an idle handler. I'm 
doubtful the event traffic coming out of at-spi to the AT could be cut 
down enough to warrant changing this approach in AT design.

cheers,
D
_______________________________________________
kde-accessibility mailing list
kde-accessibility@kde.org
https://mail.kde.org/mailman/listinfo/kde-accessibility
[prev in list] [next in list] [prev in thread] [next in thread]