Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs.
 Filter on "SUN A11Y SPAM" to ignore.

Created attachment 36012 [details] [review]
proposed patch

Is this actually correct end-user behavior?  What about deaf-blind users?

In case of tab-ing fast, the events for watched objects are anyway overwrote by
focus events. Showing those events (for watched objects) on braille is useful
only when user expects something to happen for a certain object.

I suggest that if you have speech turned on, present watched objects *only* in
speech.  If there is only Braille, then (for now) go ahead and present it only
in Braille, as they explicitly asked for a watch (we have no automatic watches).
 Similarly in magnification - if the only modality is up is magnification, then
go ahead and show the watch in magnification.  

Longer term (credit to Bill, from a phone call) is to have eventually the
ability to define a "notification area" on bigger Braille displays.

So our simple algorythm would be this:
 If speech - present in speech
 else if mag - present in mag
 else if braille - present in Braille

It doesn't make a lot of sense necessarily to show in mag or Braille, but
because the user had to *explicitly* turn on a watch, Gnopernicus will do the
best it can.

Created attachment 37882 [details] [review]
reworked patch

thinking of the 'notification area' idea, another useful feature-let for
deaf-blind users would be for gnopernicus to attach to the XKBNotifyBell events,
the way the visual bell does now, and 'flash' the braille display when a system
beep occurs (by temporarily either turning on all cells, or turning on dots 7
and 8 in all cells).  Does someone want to file an RFE?

BTW I mention this RFE here, because we could do this "beep" when a watched
object sends notification... instead of just brailling the notified content
right away.

Comment on attachment 37882 [details] [review]
reworked patch


Patch committed to head.