[BRLTTY] BrlAPI Raw key code mode?

[Dave Mielke]

Here's what I think:

We need to just go ahead and do something. If the graphical screen reader 
developers really were highly motivated to support braille well then, over the 
last several years, they'd have had some ideas and, at least once or twice, 
would've raised the issue with us. Also, if we hold a long series of committee 
meetings regarding what should be done, interest will, as usual, fade away and 
the job won't get done.

My opinion is that we simply need to start, and, as we go, using our 
improvements as they come along, we'll, slowly on, learn what else we need to 
do. Let's just get started, and then work in a way that invites lots of testing 
by our users, starting from very early on, so that we'll discover what else to 
do and also so that we won't start moving in a wrong direction. This, as may 
have gone silently unnoticed, is the very approach that has gotten brltty to 
where it is today.

Our key tables have contexts (those who know about key tables know what I'm 
referring to). This means that we don't even need a new set of key tables - we 
just need new commands which are bound within a new, persistent, GUI context, 
and a way for BrlAPI to read commands in that context.

Then, of course, we need to know what the new commands need to be. Perhaps 
someone wouldn't mind looking at Orca and NVDA in order to make a list of what 
bindable actions each of those screen readers offers. People who have access to 
JAWS, Window Eyes, Dolphin, etc could also provide lists of the bindable 
actions that those screen readers offer. We could then review all of these 
action lists with a view to determining what others have found the requirements 
to be.

We could also imagine what an initial base set of useful actions might be:

For hierarchical navigation:
   go to root node
   go to first child node
   go to specific child node (using a routing key)
   go to next sibling node
   go to previous sibling node
   go to parent node

For positional navigation:
   go one node to the right
   go one node to the left
   go one node up
   go one node down
   go to the leftmost node in this row
   go to the rightmost node in this row
   go to the topmost node in this column
   go to the bottommost node in this column

General commands:
   describe this node
   etc

We should also be brave enough to, wehre necessary, test our own changes to 
Orca, and then, if they work well, submit them to Orca as patches and/or pull 
requests. This, for example, could already be done in order to resolve the 
issue regarding skipping of identical lines and blank ends of lines.

These are just my own ideas regarding how to tackle the improving of braille 
navigation within graphical environments. Yes, they call for action rather than 
just talk, which may be why others will strive to come up with better ones. 
That's okay, though, because, as it should be, I only intend these ideas to be 
a startying point and very much do welcome better ones.

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