Samuel Thibault <[email protected]> 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 _______________________________________________ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: [email protected] For general information, go to: http://brltty.com/mailman/listinfo/brltty
