<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Also, just as much as I strongly disagree with a useful general capability<br>
being designed for only a single braille device, I equally strongly disagree<br>
with a useful general capability being designed for use with exactly one<br>
graphical screen reader. That's why I believe that brltty should define a set<br>
of useful generic commands for use with graphical screen readers in general,<br>
and then each of them can choose which ones it implements.</blockquote><div><br></div><div>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.<br><br></div><div>So what about that modifiers problem‌ that I mentioned? It seems that brltty consumes modifier key events and doesn't send them to X. <br></div><div>I've mapped keys to META and CONTROL, but by pressing these keys nothing happened.  <br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 29, 2018 at 8:22 PM, Dave Mielke <span dir="ltr"><<a href="mailto:Dave@mielke.cc" target="_blank">Dave@mielke.cc</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[quoted lines by payman shaykhmehdi on 2018/05/29 at 10:53 +0430]<br>
<span class=""><br>
>So, why not just enable brltty to accept more than one nonModifier key? <br>
<br>
</span>Because it's not that simple. The format of a command is a basic command plus<br>
options. Changing that would be very invasive and totally not<br>
backward-compatible so there'd need to be a very good reason for doing so.<br>
<span class=""><br>
>In your approach, We need to modify both brltty and Orca, and every time Orca<br>
>adds a command (maybe) we must add a BRL_CMD_... . But if it would be possible<br>
>to handle more than one nonModifier key, We can use Orca commands just by<br>
>defining some key table bindings.<br>
<br>
</span>And if Orca ever changed a keybinding then we'd have that very same problem.<br>
It's poor programming style for a communication layer between two aplpications<br>
to depend on the current user interface ideosyncracies of one of them. The<br>
inter-application communication layer should, in other words, be very<br>
well-defined. It shouldn' be volatile in any way so that, if at all possible,<br>
it'll remain stable and backward-compatible.<br>
<br>
Also, just as much as I strongly disagree with a useful general capability<br>
being designed for only a single braille device, I equally strongly disagree<br>
with a useful general capability being designed for use with exactly one<br>
graphical screen reader. That's why I believe that brltty should define a set<br>
of useful generic commands for use with graphical screen readers in general,<br>
and then each of them can choose which ones it implements.<br>
<div class="HOEnZb"><div class="h5"><br>
-- <br>
I believe the Bible to be the very Word of God: <a href="http://Mielke.cc/bible/" rel="noreferrer" target="_blank">http://Mielke.cc/bible/</a><br>
Dave Mielke            | 2213 Fox Crescent | WebHome: <a href="http://Mielke.cc/" rel="noreferrer" target="_blank">http://Mielke.cc/</a><br>
EMail: Dave@Mielke.cc  | Ottawa, Ontario   | Twitter: @Dave_Mielke<br>
Phone: +1 613 726 0014 | Canada  K2A 1H7   |<br>
______________________________<wbr>_________________<br>
This message was sent via the BRLTTY mailing list.<br>
To post a message, send an e-mail to: BRLTTY@brltty.app<br>
For general information, go to: <a href="http://brltty.app/mailman/listinfo/brltty" rel="noreferrer" target="_blank">http://brltty.app/mailman/<wbr>listinfo/brltty</a><br>
</div></div></blockquote></div><br></div>