nano-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nano-devel] [nano] improving accessibility


From: Enrico Mioso
Subject: Re: [Nano-devel] [nano] improving accessibility
Date: Sat, 10 Sep 2016 08:52:30 +0200 (CEST)

Hi Benno.

It's amazing to see this much interest on those topics: I am doing my best to 
answer your questions, and hoping my answers are right, and good.

How many keys are present on the braille display may depend on the braille 
display itself. From now on, I'll refer to my own braille display.

The braille display can currently display 40 characters at a time; so a line 
may be seen as successive 40-characters parts, more or less.
So I may:
- move up or down to other lines
- move to the "right": displaying the next piece of the line
- move to the "left": go back to previous line piece
- as you guessed incredibly right: "back to cursor" key, which takes the 
braille window where the cursor is.

The last described key also serves the purpose of "undoing" the last cursor 
movement: if the application moves the cursor, or I move it somehow, or it gets 
one line down due to a program displaying output, this key takes me where the 
cursor was previously. I didn't play enough with this feature to understand it 
completely: the BRLTTY Team can for sure answer this better.
Testing in a shell with code snippet like this:
while [ 1 ]; do sleep 1;echo ciao;done
And starting at line 8, after each print of "ciao" I can press the "back to 
cursor" key, and it will always take me at line 8, where it was when the all 
thing started.
Infact, pressing enter causes the cursor to move, so BRLTTY remembers where I 
was before pressint the enter key.
BRLTTY is incredible: it can also interact with the input layer and do various 
things with keystrokes, but I know little about this for now. I use this 
software practically always, but tend to use it's basic functionalities most of 
the times.
Intercepting incoming keystrokes, optionally, the software can let you "type" 
as you where using a mechanical braille writing machine, we call it 
dattilo-braille here, but I am not sure this is the right name.
More importantly, BRLTTY can inject keystrokes: so it can type the right 
character based on key combination you type. I don't use generally this mode of 
operation, at least for now.

In general then, it's possible to access some specific funcitonalities of 
BRLTTY (preferences menu, help text and so on), by pressing some key 
combinations on the braille display. This may vary a lot depending on the 
braille display in question. Using available braille display keys, you may also 
interact with the system, such as when copying/pasting text across different 
windows / terminals. On may braille displays then, there is a row of keys, in 
my case superposed to the set of cells I can touch to read the text: those are 
called "routing keys" and their function may vary depending on how you use them 
(e.g.: if you press other keys while pressing them).
Generally, I use them:
- to select text to copy / paste (pressing them in combination with other keys)
- to ask BRLTTY to try to move the real cursor where the letter of text under 
the pressed routing key is;

My braille display is an Alva BC640: but I tell this only to give you some 
reference data, not expressing an opinion.

Regarding the screen position: in text-mode there are a set of cells (2
characters) used to tell me where I am on the screen. Here, letters from a to y 
are used to indicate I am in one of the first 25 lines of the screen. From now 
on, those letters repeat, but they start blinking at different speeds to 
help me distinguishing between line 2, 26 and so on. On graphical-mode, all of 
the things I described, or some of them, may change: since here things works 
differently here.

Regarding the boot sequence or administrative tasks: from a system perspective, 
from the moment on the kernel started init, it should be possible for me to 
start brltty and have access to the console. Brltty can be used on initrd 
images also. If thesystem crashes before invoking something init-like, then you 
maybe in trouble, at least with this display I guess, or in general with a 
display needing specific protocols. I don't think mine can operate without 
that, but maybe I am wrong?

At that point, you can use dmesg; and you are going to see all prints generated 
by things started after brltty.
Then dmesg maybe your friend. Handling a remote system connected to your with a 
serial console then becomes possible, and here you may capture also kernel 
output. On OpenBSD and other *BSDs, brltty can operate only if something (some 
other software), gives him the possibility of reading what's on the screen 
somehow (e.g.: GNU Screen + patches). This makes it more complicated in my 
opinion to handle the system if something gone wrong.

Regarding nano, I am using version 2.7.0, and for sure I have the git repo 
cloned here.
I use my own systems usually, at least for now, so probably I unset'ed some 
things just to be "sure". And thank you very much for your hints, I hsould 
update my config file, I am carying it with me across different systems / 
upgrades I guess.
I am using currently Archlinux, AUR enabled.

My computer never bothers to start X :) I like this definition. But I know 
various blind people does use X + GNOME (or maybe probably Mate I guess) + 
brltty + ORCA screen reader. But for now I feel more agile in terminal-land, 
even if I may give the GUI a try. For now I am working on an EEE pC 701 
computer (but with an external SB keyboard), so working in text-mode helps me 
not using lots of resources in some sense.

Regarding the history: I disabled it since I would like nano to show things I 
typed on this session, not previous invocations. And so I didn't want that 
~/.nano_history file appear on my home. But I think this is a matter of habits 
or something like that, nothing accessibility-related in here.

Regarding noconvert, you maybe right. In general I find the statubar useful, 
and try to look at it sometimes: for sure I apreciate the "beep" at the PC 
speaker (in my case "simulated"/handled by Intel HDA audio driver), to alert me 
about non-writability of a file.
But, yeah: anyway I end up noticing the ^Ms, and sometimes removing it using 
the Verbatim functionality within search/replace. :)

I used ^S sometimes to stop output in the terminal, but not on nano.
And I guess your suggestion is very very nice :) I may give it a try! :) Thank 
you very much, again! I apreciate a lot all of this suggestions.

Regarding colours: I meant that I don't use them in my computer, but I try to 
maintain some sense of colour in life :) . No, I don't use any kind of 
syntaxcolouring, at least not consciously at the moment.
I don't watch at colour attributes enough: BRLTTY represents them in a way I 
haven't bothered to understand for the moment, my fault.

And... yes - to compose mails I use nano. And I use it for programming when 
this happens, and in general when I need a nice editor. :)
I don't dislike other editors, but I didn't use them enough I guess, at least 
for now.

Regarding mails: I use Alpine, even having configured mutt just in case (since 
Alpine development doesn't seem very active those days).

Thank you very much for your questions and interest, hoping I answered them.
You guys are free to send me any question / anything else ingeneral. :)

Thanks for all, really,
Enrico



reply via email to

[Prev in Thread] Current Thread [Next in Thread]