[BRLTTY] BrlAPI Raw key code mode?
Samuel Thibault
samuel.thibault at ens-lyon.org
Sun Aug 27 11:34:24 EDT 2017
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.
- add brlapi_getModelName(void) so the application knows what values it
should expect from readKey.
- 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.
- 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.
Do we agree on these?
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.
Samuel
More information about the BRLTTY
mailing list