[BRLTTY] problem with defining some key bindings

payman shaykhmehdi payman.shaykhmehdi at gmail.com
Wed May 30 04:32:52 EDT 2018


>
> Also, just as much as I strongly disagree with a useful general capability
> being designed for only a single braille device, I equally strongly
> disagree
> with a useful general capability being designed for use with exactly one
> graphical screen reader. That's why I believe that brltty should define a
> set
> of useful generic commands for use with graphical screen readers in
> general,
> and then each of them can choose which ones it implements.


I You're absolutely wright, thats why I suggest to use multiple keys in a
command, but I thought it is easy to do that.

So what about that modifiers problem‌ that I mentioned? It seems that
brltty consumes modifier key events and doesn't send them to X.
I've mapped keys to META and CONTROL, but by pressing these keys nothing
happened.

On Tue, May 29, 2018 at 8:22 PM, Dave Mielke <Dave at mielke.cc> wrote:

> [quoted lines by payman shaykhmehdi on 2018/05/29 at 10:53 +0430]
>
> >So, why not just enable brltty to accept more than one nonModifier key?
>
> Because it's not that simple. The format of a command is a basic command
> plus
> options. Changing that would be very invasive and totally not
> backward-compatible so there'd need to be a very good reason for doing so.
>
> >In your approach, We need to modify both brltty and Orca, and every time
> Orca
> >adds a command (maybe) we must add a BRL_CMD_... . But if it would be
> possible
> >to handle more than one nonModifier key, We can use Orca commands just by
> >defining some key table bindings.
>
> And if Orca ever changed a keybinding then we'd have that very same
> problem.
> It's poor programming style for a communication layer between two
> aplpications
> to depend on the current user interface ideosyncracies of one of them. The
> inter-application communication layer should, in other words, be very
> well-defined. It shouldn' be volatile in any way so that, if at all
> possible,
> it'll remain stable and backward-compatible.
>
> Also, just as much as I strongly disagree with a useful general capability
> being designed for only a single braille device, I equally strongly
> disagree
> with a useful general capability being designed for use with exactly one
> graphical screen reader. That's why I believe that brltty should define a
> set
> of useful generic commands for use with graphical screen readers in
> general,
> and then each of them can choose which ones it implements.
>
> --
> I believe the Bible to be the very Word of God: http://Mielke.cc/bible/
> Dave Mielke            | 2213 Fox Crescent | WebHome: http://Mielke.cc/
> EMail: Dave at Mielke.cc  | Ottawa, Ontario   | Twitter: @Dave_Mielke
> Phone: +1 613 726 0014 | Canada  K2A 1H7   |
> _______________________________________________
> This message was sent via the BRLTTY mailing list.
> To post a message, send an e-mail to: BRLTTY at brltty.app
> For general information, go to: http://brltty.app/mailman/listinfo/brltty
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://brltty.app/pipermail/brltty/attachments/20180530/914318b3/attachment.html>


More information about the BRLTTY mailing list