[BRLTTY] BrlAPI Raw key code mode?

[Mario Lang]

Dave Mielke <dave at mielke.cc> writes:

> [quoted lines by Shérab on 2017/08/20 at 11:26 +0200]
>
>>I share Samuel's fear that is will be difficult to design something
>>which is generic enough. What can we do beyond returning the keycodes
>>themselves or brltty commands, as we currently do?
>
> What I suspect we need is a set of commands that reflect how one works within a 
> graphical environment (perhaps things like hierarchical window navigation, 
> going to the navigation root window (home screen), going up one level, etc). 
> Then we could design key tables for that, and brltty (and via BrlAPI) could be 
> used to naturally work within that environment.

I think we already have something like that, a predefined set of
commands.  The problem is, that we can not predict what a BrlAPI client
actually wants to do.  So we can make some assumptions about how a
graphical screen reader works, but this will likely always be limiting
to some types of clients (that might not even be written yet).

Also, I am wondering how clients are going to implement their own
bindings.
JAWS for instance has an interactive key binding editor which is very
nice for users.  You can define a new binding for a screen reader command by
simply pressing the desired key combination interactively.
I am suspecting that some BrlAPI clients would like to do something
similar at some point.  Especially if the set of screen reader commands
grows.  Some of these commands might not be bound by default to
anything, waiting for the user to customize a binding if they really need the
command.

If I haven't overlooked something, to me, what is missing is a way
for the client to query the actual model the driver has
detected.  With that, a client could implement their own key code
handling, because they actually would know what they can expect from a
readKey call.  The client would still need to do their own key code
handling, which seems fine to me if what is desired is more control.
Exporing our knowledge of how certain NavigationKeys are named could
also help the client to avoid duplicating too much stuff.

In any case, if we proceed with an attempt to generalize for graphical
screen readers, we really should talk to Orca dev what they actually
would want to have.  They might have some insights that we haven't
thought about yet.

-- 
CYa,
  ⡍⠁⠗⠊⠕