Re: [orca-list] Small bug when using BRLTTY in a graphical terminal

[Samuel Thibault <samuel thibault ens-lyon org>]

Sébastien Hinderer, le jeu. 28 avril 2022 10:55:36 +0200, a ecrit:
> Samuel Thibault (2022/04/28 10:45 +0200):
> > Sébastien Hinderer, le jeu. 28 avril 2022 10:42:03 +0200, a ecrit:
> > > and, if Orca does not render a widget in braille, then it shouldn't
> > > talk either, I don't know.
> >
> > Orca does render the widget in Braille, it's just not shown.
> >
> > > theone of brltty takes precedence?
> >
> > Yes.
>
> Woulnd't we need, then, a third protocol to decide, on a per-widget
> basis, which screen reader renders it?

That'd be tricky. The problem is to get to agree. If the screen
readers have to agree at each widget switch that'd be very heavy. The
granularity could be coarsened to a whole application window. But the
problem still remains tricky: we'd need readers to know about each
other, to be able to know whether it should expect getting an answer
from the other as to whether it'll have more priority or not. One could
just let them all start rendering the application and shut up as soon as
the other notifies that it should get priority, but then that'll produce
spurious output at each application switch, that'd be chatty. The
underprioritized reader would have to cancel its own output as quickly
as possible.

The good point in the way that Braille is handled is that it's the
rendering server (the BrlAPI server) that selects what should be shown.
(One thing that we don't do that would be useful would be to notify the
screen reader that is shadowed, to let it avoid processing events etc.
while its output is shadowed, and notify it again if it gets unshadowed)

In the speech case, there is no such notion of cooperation, there is
only a notion of message priority that allow notifications etc. overtake
normal screen processing. Possibly we could introduce inside the speech
server the same priority notion as the brlapi server has, which readers
will raise and lower depending on how confident they are in the quality
of their output, just like is currently happening with Braille. Then the
server can actually process messages from only one screen reader at a
time. I however wonder about the nasty details we might have to fix up
for the notifications etc. Typically, if one screen reader A sends some
message, and then the other one B (that has to take precedence) sends
another message, we could cancel the message from A, hopefully before it
got too much audible from the sound board.

Samuel