[BRLTTY] Chords in brlapi

[Dave Mielke]

[quoted lines by Peter Nilsson Lundblad on 2014/02/17 at 20:46 -0800]

>1. To get raw dots instead of characters as input.  If using e.g. liblouis as 
>a translator, this is necessary, otherwise we'd be using brltty's tables for 
>input and liblouis for output which would be inconsistent and also not support 
>anything but non-contracted computer braille.  

Good point.

>Ideally, an api client would be able to choose at runtime if it wants braille 
>cells or characters instead of relying on a system-wide flag, but that's 
>slightly off topic.  

Nothing is off-topic. I think we could actually provide this simply by checking 
whether or not the client has accepted the range for the PASSDOTS command. If 
it has then it gets dots else it gets characters.

>I think we need to keep this part of the feature, and according to my testing 
>it seems to keep working.

I'm not sure what you mean by "it seems to keep working".

>2. "Raw" chords could be one way of extending the available command set beyond 
>the ones that brltty provides for displays that support chords without loosing 
>the rest of brltty's keymap functionality. The idea would be that an api 
>client would handle its own mappings for chords on its level (since they use 
>similar keys on all displays that have braille keyboards), while navigations 
>keys etc. which vary significantly between displays would be taken care of by 
>brltty's existing mappings.  

that'd be one way to implement client-specific commands, although it'd also 
disable brltty's standard chord bindings (see brl-chords.kti).

>I don't think this is a strong enough argument to ressurect this feature if we 
>could find another way of extending the command set for different api clients.

This'd be my preference as it'd also integrate with brltty's help facility.

Passing raw dots to the client based on whether or not it's accepted the 
PASSDOTS command is easy. Reviving support for chords, however, is a bit more 
difficult. The problem is that the key combination has already gone through key 
table processing. We could have a mode which causes key table processing to 
yield the chord, rather than checking further in order to map it to a bound 
command, but we'd then need to decide what the core should do when it sees a 
chord. In other words, that mode would break the core unless we come up with a 
further idea on how to fix that.

-- 
Dave Mielke           | 2213 Fox Crescent | The Bible is the very Word of God.
Phone: 1-613-726-0014 | Ottawa, Ontario   | http://Mielke.cc/bible/
EMail: dave at mielke.cc | Canada  K2A 1H7   | http://FamilyRadio.com/