I'm starting to get used to work with an Alva BC640. I still highly regret my former Brailliant 40 which I think had more efficient controls than the BC640.
This being said, I think that many things could be done to improve the user experience with the BC640. First of all, this double cursor routing emulation is actually horrible. To emulate an non existant second row of cursor routing keys, the device let you hold a key and if held long enough the second row key events is generated. This makes the normal first row bindings very awkward to use since their events are not reported until the key is actually released. This causes many problems: 1) If the routing key is not released quickly enough, the second row key event is generated. Configuring a longer delay makes the bindings using the second row more annoying to use. 2) Releasing a key combination containing a routing key too quickly leads to unpredictable results as the thumb key may be released first while the press event for the routing key has still not been sent due to the waiting delay needed to distinguish between the first and second row emulation. So, e.g. instead of doing a cut begin operation, you may get a window movement followed by a cursor tracking operation to some unexpected location which is very, very annoying. 3) Movement bindings currently using the second set of routing cursor keys are obnoxious as you need to wwaaaaiiiit for the emulation timeout to occur. Unless you are an unseasoned braille display user, those extra delays are slowing you down in your operations, adding to the frustration. Next, the bindings themselves are suboptimal. Some movement bindings are done with the thumb keys, and some others are done with the etouch keys. This makes busy screen navigation less optimal as the hands have to move away from the thumb keys and back. Furthermore, the thumb keys are much more rugged than the etouch keys so it is best to put frequent repetitive key actions on those and confine the more fragile keys to miscelaneous functions such as copy/paste which are not solicited as much. So... I've reworked the bindings: 1) to make movement bindings more efficient 2) to remove any RoutingKey2 bindings And finally, make the driver mask any RoutingKey2 event and turn them into RoutingKey1 events. So, even if the device still try to emulate those non existant keys, the driver would still report those events as being the same keys. This way, all the bindings would work whether or not the emulation feature is enabled in the BC640's configuration. Things work better if the emulation is turned off, but even when turned on the effect is then much predictable. I really think that if we want to support this kind of behavior, that should be implemented in BRLTTY rather than in the device. For example, to complement the ! key binding qualifier, we could introduce an additional one that would denote a held key i.e. the binding would be triggered by such a qualified key when it is held for more than a certain delay. Follows a series of patches providing the presented changes above. Nicolas _______________________________________________ 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://mielke.cc/mailman/listinfo/brltty
