Hi Aura, Aura Kelloniemi (2017/09/01 08:01 +0300): > 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.
For a key which is not consumed by the client, that may make its processing very slow, even from a user experience perspective, IMO. Shérab. _______________________________________________ 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
