[BRLTTY] Unconventional key bindings was Re: Many problems and questions on brltty for android

Mon May 13 11:57:36 EDT 2013

At the request of Mario, on key bindings.

First, the cursor routing keys.  Conventionally perform the default action for the current item when not in an edit field.
In brltty the first few are assigned to functions: r1routs the focus to the accessibility soft curser, r2 performs a double tap, R4 scrolls up one page, R5 scrolls down one page.  I haven't been able to figure out what r0 and r3 do.  The installation guide states,
"In any other context, however, a cursor routing key performs an action on the 
screen element under it. Starting with the leftmost routing key over a 
screen element, which we'll call key #0, the actions are as follows:

   0  Set Accessibility Focus (used for cursor tracking and routing)
   1  Click
   2  Long Click
   3  Scroll Backward
   4  Scroll Forward"
So, we may need to update this.  Also, this info properly belongs in the help screen with the rest of the key bindings.  It might be there at the bottom.  I haven't made it all the way through the help screen yet.  Just taking a while to adjust.

Scrolling the screen is a powerful feature and should be easily accessible, but it doesn't belong on the router keys.  It could be assigned to one pare of the f1 through f4 keys.  Or there could be some other binding for it depending on how else you move the furniture around.

I've noticed that brltty displays things oddly.  For example, when I look at my settings list, I see one icon in the list at a time.  When I look at the soft keys at the bottom of my phone, I see all three soft keys at once.  When I look at the help screen, brltty busts up the word at the end of each line and puts half on one window and half on the other.  I just checked and it doesn't do this in other apps such as the text messaging app.  It's actually really intuitive about wrapping words properly.

What I'm thinking is, and I don't know how possible it is because of the way accessibility services are built, The cursor routing keys should perform cursor routing functions for the item below the router key.  All keys 0 through 31 in my case, perform the same actions, but on a different object depending on which key is pressed.
single press, rout the focus to the accessibility soft cursor if cursor tracking is turned off.
Double press perform a double tap on the item under the key.
Tripple press perform a double tap and hold.

For efficiency, I would like brltty to display as many objects as will fit on the display.  So, if I'm looking at my settings screen for example, I want to see three or four settings icons at a time, in the same manner as I currently see my soft keys displayed.

So, suppose i'm looking at my settings screen and I have the list showing sound, display,, storage, battery…  Right now each of these is showing in a separate window, even though they all fit into one window.  If all four of these icons were displayed in one window and I wanted to see what was using the battery and the battery icon started on cell 25 through 31, then a single press of any router key 25 to 31 would rout the cursor to the battery icon.  A double press would double tap the battery icon and open the battery usage window.  A triple press would do a double tap and hold.  In the same scenario, pressing router keys 0 through 2 would act on the sound icon.

I realize that may represent a huge change and may not even be possible, but if in a later version it could be implemented, it would be a very welcome change.

All the navigation options are really unconventional.  I'd change them all if I could.  First, I'd take them off of the display keys and put them on the braille input keyboard.  Second, I would make them conform to what some people call note taker standard or others call Blazey standard which all the notetakers that have ever been make use of.
Space 1 and space 4 move levt or right one letter.
Space 2 or space 5 move left or right one word.
Space 3 or space 6 move left or right one sentence.
Space 23 or space 56, move left or right one paragraph.
Space 123 or space 456, move to the top or bottom of the window or input text.
Space 12 or space 45, move to the previous or next object or window.  Note that in the case of some note takers the order is backwards for the first three sets.  So characters are on the 3 and 6 while sentences are on the 1 and 4.  Depending on the notetaker.

Brltty has functions that equate to most if not all of these.

D2 and D5 in brltty pan the display left and right wich is very standard and nice.

Some keys which aren't conventional and which I can't see the rational for at all:
Show time and date is D1 plus d5.  Letter E shows the time and date?  Not t for time or d for date.
Status bar is d2 d5.  The colon sign?  Not d3 d4 the ST sign which is standard on most platforms.
Learning mode took me a while.  1456 is the computer braille question mark, but not many people know that until they've been using braille displays for a while.  Not sure in all fairness what I would make that one.
Grade two translating.  This one threw me for a loop forever.  I'm reading it for the 10th time and I've only just now gotten it.  Brltty looks at grade two translating in a strange and not quite correct way.  It recognizes the difference between 6 dot and 8 dot braille, but not the difference between grade 1 and grade two braille.  So, when I set up brltty for the first time, I chose two braille tables in the settings Presumably where I chose a 6 dot english grade two translation table, I could also have chosen a 6 dot english grade one translation table.  Brltty makes the functions for 6 and 8 dot and grade one or two into one translation function which some other platforms do as well.  From a programmer perspective as some one who uses 8 dot braille for coding, this approach makes a kind of sense.  My clients will be using brltty on their android phone as a communication aid though and they'll be thinking in terms of grade one or grade two braille.  Conventionally, the switch between grade one and two has a 1245 or letter G in it somewhere and so my clients will be expecting this.

Brltty has two different approaches to toggle settings.  One, such as turning the help screen on and off or turning the tutorial on and off requires one keystroke which turns the setting on or off depending on it's current state.  The other approach such as the case of turning cursor tracking on or off or switching between 6 and 8 dot braille requires one key combination to turn the setting one way, and another to turn the setting the other way.  I like the first approach.  For example, I'd get rid of the 235 and 236 keystrokes to switch between 6 and 8 dot braille and replace them with one, either 1245 G, or 2345 T.  I'd get rid of the d1 and d3 to turn the cursor tracking on and off and replace it with a 14 C or something.

When we get into the keystrokes for use with the braille input keyboard a lot of them appear to be using the joystick as a sort of modifier key.  for example, Enter/leave the status display is press plus b5.  In other words, press the centre of the joystick and dot 5 on the braille keyboard to enter the status area.  Similarly, a few of the navigation keystrokes seem to be using the keys on the braille keyboard as modifiers for presses of the joystick, such as b4 + left or b4 + right go to the beginning or end of the line.  Not especially compliant with notetaker conventions, or really any other braille system I've ever used.

I also have to say, I'm not a heavy joystick user.  It's not a very comfortable joystick for one thing.  I love my braille connect, but don't really consider the joystick  a key feature.  Same with the space bars.  At least using the space bars as modifier keys is comfortable on the fingers and conventional across screen readers and operating systems.

I'm not even sure at this point how many of the functions I'm reading about actually apply to android.  For example, Does brltty on my android device really have a function to go to the next or previous command prompt or next and previous different highlighted text?  How about the next or previous virtual terminal?  I don't honestly know.  I'm sure android has a shell in it somewhere that you could hack into if you really wanted, but if the tutorial mode isn't enabled yet, then I doubt shell integration for android is all that.  So,  if things aren't finished yet, or if commands aren't applicable, why are they documented in the onboard help on my device?

As I'm reading this and trying to come to grips with it, I'm realizing that a lot of the features are geared towards programming and console applications.  As such, they're rockin.  I know programmers who if I could get them to read braille, would get a lot of use out of the functions.  I'm not sure how well they translate to an end user GUI though.

I'm not a programmer, but I am good at designing, documenting, testing, training, and maybe one or two other skills that aren't useless.  If there is anything I can do to help,  I'll be happy to contribute.

Erik Burggraaf
Follow my series of articles about setting up a small business through the ontario disability support program at http://www.erik-burggraaf.com/blog
Ebony Consulting toll-free: 1-888-255-5194
or on the web at http://www.erik-burggraaf.com

On 2013-05-13, at 5:49 AM, Mario Lang <mlang at delysid.org> wrote:

> erik burggraaf <erik at erik-burggraaf.com> writes:
> 
>> I have read through the help down past all the uses of the display
>> keys and now I'm discovering that most of the functions are actually
>> repeated on the braille keyboard using, if possible, even less
>> sensible combinations than what they had on the display keys.  I've
>> got to take this in baby steps or I'll get fed up.
> 
> While I try to stay as neutral as possible, I'd like to make you aware
> that your tone is not producing any good feelings while I am trying to
> support you.  Indeed, if everyone were to write in a tone like this, I'd
> probably given up to support free software questions long ago.
> 
> You could, for instance, let us know which key bindings in particular
> you find unintuitive, and how you would propose to change them.  That
> would be constructive criticism.
> 
>> So, my question is, is there a backspace on the braille input keyboard?
> 
> Yes, Space+Dot7 should be bound to KEY_BACKSPACE, and Space+Dot8 should
> be bound to KEY_ENTER.  Now that you mention it, I remember having had
> problems to invoke Backspace in an Android input field as well, so there
> might still be some work to do.
> 
> -- 
> CYa,
>  ⡍⠁⠗⠊⠕
> _______________________________________________
> This message was sent via the BRLTTY mailing list.
> To post a message, send an e-mail to: BRLTTY at mielke.cc
> For general information, go to: http://mielke.cc/mailman/listinfo/brltty

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mielke.cc/pipermail/brltty/attachments/20130513/314b1b3d/attachment.html>