[BRLTTY] BrlAPI Raw key code mode?

[Aura Kelloniemi]

Samuel Thibault <samuel.thibault at ens-lyon.org> writes:

 > Dave Mielke, on ven. 25 août 2017 17:27:45 -0400, wrote:
 > > [quoted lines by Shérab on 2017/08/25 at 22:47 +0200]
 > > 
 > > >> Each client specifies which key ranges it'll handle. Those key ranges are for 
 > > >> values derived from key table processing. In other words, key table processing 
 > > >> occurs before determining which client should get any given key code, so key 
 > > >> table processing is common to all clients. Perhaps I'm missing something, but, 
 > > >> to me, that gets in the way of clients defining their own commands.
 > > >
 > > >Indeed. That's why I suggested to provide the keybindigns processing
 > > >code as a library. That way this could be done by each client and the
 > > >code would still be shared.
 > > 
 > > I don't see how that'd work. If a client specifies raw key codes then it gets 
 > > everything. That only allows for one client at a time. It also doesn't allow 
 > > for xbrlapi to be running in order to handle input.

 > AIUI, an application which would use a different binding than the brltty
 > commands would have to be responsible. I.e. if it only supports a set of
 > key events, it should only request the brltty daemon to send these, and
 > let the daemon send others to other clients, if any, such as xbrlapi.

I would prefer the interface to be such that BRLTTY sends the raw key codes
(or commands, or maybe even both) to a client. Then the client responds to
BRLTTY whether it actually consumed the key or not so that BRLTTY can pass the
same code to another client. This could be done in a callback style where
BrlAPI calls a callback function in a client, which then returns a boolean
value indicating whether the key should be further processed or not bt BRLTTY.
Another option is that the client polls for the key codes and then calls a
BrlAPI function to requeue the command, if it did not care about it.

I use the words command and key code here interchangeable, because
this can apply to whichever is being sent.

Actually sending both the BRLTTY command code and the raw key code to client
applications could be useful (especially if combined with Dave's suggestion
regarding a special GUI context). This way the client can reuse a common base
set of commands (from whichever BRLTTY context that it likes) and still allow
the user to redefine keyds and add new commands as required by the specific
application. Whenever a user presses a key combination that BRLTTY cannot
translate into a command it would send a special command code like
CMD_UNKNOWN. If an incomplete key chord is being pressed by the user (a key
combination which might turn into a valid BRLTTY key binding by a subsequent
key press), then BRLTTY would send CMD_INCOMPLETE along with the raw key codes
until the chord becomes complete (either CMD_UNKNOWN or some known BRLTTY
command).

This idea might not be very difficult to implement, and it allows for maximum
extensibility (both from the user's perspective and from the application
programmer's), because applications can add new commands, reuse predefined
BRLTTY commands and also add whatever exotic key handling quirks they want to
implement - something that BRLTTY's current key event handling cannot do, like
supporting extra long key presses for instance. Later on, if we find it
useful, we can then add the whole key table management infrastructure to
libbrlapi.

I feel that only adding new generic commands to BRLTTY (without somehow
allowing the user to add new bindings on a per-application basis) is too
restrictive to power users.

-- 
Aura