[g-a-devel]AT-SPI Addition to Signal Handler in at-bridge

[Marc Mulcahy <marc mulcahy sun com>]

Hi All,

Just comitted an adition to at-bridge which does the following:

1. Provides separate notifications for text-changed::insert and 
text-changed::delete so an AT can make more sense of text-changed events.

2. Passes on event details for all events if either of the first two 
parameters to the signal handler are ints.  This way an at can actually 
know what text was inserted.

This raised an interesting an not so happy issue: how can an at tell what 
text was deleted.  By the time the AT receives the text-changed::delete 
notification, the text is already gone.  A common use case is for a screen 
reader to speak the text that is deleted (when backspace is pressed, the 
screen reader speaks the character which was deleted).  There are two 
possible hacks which I don't like:

1. The screen reader could intercept the backspace and other deletion 
keystrokes (control-delete for example) and speak the appropriate text 
before passing the keystroke on to the application.  This has the serious 
disadvantage that the screen reader must know what keystrokes are used by 
the aplication to delete text.

2. The screen reader could cache a copy of the text contents and could 
speak portions of the cache when text deletions are signaled.  But, this 
seems bad, since who knows how large the text buffer will be.  (Maintaining 
a cache of World and Peace would be dreadful).

This issue stems from the fact that the event notifications in at-spi are 
one-way, and for good reason (mainly to prevent an AT, or lack there of, 
from blocking a running application).

Any thoughts?

Marc