[BRLTTY] BrlAPI Raw key code mode?

[Mario Lang]

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

> Hello,
>
> Just to try to summarize a bit what I get from the discussion (I
> couldn't really participate to the thread for lack of time, sorry), what
> could be implemented right away without actual discussion because they
> have clear semantic are:
>
> - make brlapi return keycodes for drivers which were converted to using
>   key tables.

This already works!  I am using it with 5.5.  Commit
5cf1b9e9303278019e6a74141cf276a9f03dd2db fixed a minor issue about
needing to accept the key range explicitly, but that should be it.

> - add brlapi_getModelName(void) so the application knows what values it
>   should expect from readKey.

That would be a nice to have.  Shérab said something about a
properties system he'd like to integrate this idea with.  I personally
would be fine with a new function name like you mentioned above.
I wouldn't call it ModelName though, I think ModelIdentifier (or
similar) would be more appropriate.  After all, it is not really a model
name that is being returned (if you are going to use brl->keyBindings).

> - add brlapi_getRawKeyName(code) which returns as a string the name of
>   the key as brltty knows it (e.g. B1, B4, SpaceLeft, LeftRockerTop,
>   ...) so that the application can implement nice keyname-to-action
>   configuration for the user.

Yes, please. (Or, see below.)

> - add brlapi_getKeys(void) which returns the set of keys known to be
>   available on the model.  I however don't think the brltty core knows
>   that yet?  I'm also not sure how useful it is to applications.

Since we have key name tables, at least as far as I know, we tend to
know the set of possible keys per model.  I am not sure if this is true
for all drivers, but it should be for most.

> Then there is the question of defining generic translations.
>
> - We currently have the BRLTTY commands, but they are considered not
>   generic enough by clients (there is for instance no parent/child
>   browsing, needed by graphical environment).
>
> - We could just let applications do their own translation from the
>   existing keycodes, but AIUI the fear is that it will be a mess of
>   varying tables on the client side etc. And also clients don't own all
>   kinds of braille devices, it's hard for them to define them.
>
> - We could add other bindings within BRLTTY, that brlapi could return
>   instead of commands and keycodes. The fear is that it'll be hard to
>   define something generic.
>
> - It'd be sad not to leverage BRLTTY's nice keybinding management.
>   Perhaps it could be put on the client side within libbrlapi. That's
>   a bit like xkb.  Then there is still the question of having standard
>   sets of commands, but at least the question will have gotten away from
>   source code.

Hmm, there is an idea there!  I have to admit that I neither find the
idea of inventing yet another static mapping, nor the idea of continuing
to force clients to reuse our mapping very convincing.  However, making
it possible to load a key table from the BrlAPI client side sounds pretty interesting.
It might require quite some shuffling of code, and there might be
some issues with (as far as I know) our set of commands being
hardwired (i.e., a key table can not define commands right now).  But if
that were somehow managable, a BrlAPI client could specify their own key
table directory, and load a table according to what
brlapi_getModelName() returns (or something to that effect).
With this, we could even try and still meet the generalisation goal.
All we need to do is ship our idea of how graphical user interface
navigation keys should behave.  Clients like Orca can switch over to the
new mapping, or invent their own (possibly just slightly modified) version
if need be.

However, this sounds like a rather huge diff, actually.  So, what do
people actually familiar with the details think about the idea?

P.S.: Why do I keep thinking about the Design By Committee reference I
read here a few hours ago :-).

-- 
CYa,
  ⡍⠁⠗⠊⠕