[LAD] Interface development for the blind (starting from Bristol)

[Julien Claassen]

Hello Nick, hello all other interested devs! :-)
   I just tested the first version of the CLI from Bristol. In general it works 
fine. Very easy, the cursor keys work, the display is just fine. The value and 
parameter name are not so far apart, that they wouldn't fit on 40 characters. 
So even better. Something to behold, for really cool CLIs, that blind people 
should find useful. A braille display has mostly 40 chars. The display can 
usually be set to the left or to the right, no middle position. At least I 
never saw anyone doing that. So if you have pairs of information, try to put 
them in one or the other half of these 80 chars, not somewhere in between.
   One thing, that the Bristol CLI still lacks, is cleaning up the console 
settings. If you use readline or other curses functionality, you need to 
stored the settings of the terminal, before you start curses. Readline has 
it's own set of functions to do that for you. There you only need to take care 
of interupt handlers. When your done executing, you need to restore the 
original settings. Otherwise you get non-appearing keystrokes in the shell, 
prompts appearing anywhere, but not where they should be.
   So then Nick has put some other questions to me, about how to continue, 
which I think is very helpful to others, who might be interested.
   For the readline interface. Setting a filter parameter say with the command 
"filterset". In Bristol you'd type ':' for the readline mode and then you'd 
do:
filt<TAB>
   This should complete as far as possible, or you do:
fit<TAB><TAB>
   which should display all possible matches. Meaning: commands, that start 
with filt. Just the usual behaviour, because one is used to it. Even in CLIs 
there are parts of intuitivity. It's just different from the GUI intuition. 
:-)
   About quicker navigation. Finding a parameter you wish to change:
:find cutoff
   Brings you to all params containing the string "cutoff". Although in this 
case I'd even go for:
/cutoff
   (in VI terminology). But no problem with find or search.
   A short word on TAB-completion in Readline. It's a standard feature. With 
nothing configured, it will complete filenames. But you can supply readline 
with your own list of commands. An easy example can be found in the readline 
info pages. I suspect a much more complex yet marvellous example is asterisk's 
CLI mode. It was only designed for a bit of controlling, testing and 
debugging, I suspect. But it understands things like:
co<TAB>
[making]
core 
So you go on with this line:
core shu<TAB>
   I never figured out how to best write code, that will notice spaces and find 
the next word it can complete. Not necessary, but if you have something 
complex, huge and feel there's a need for it. Those guys did it and did it 
well. I hever had to complain. :-)
   A word on help. Bristol speicific: just use :help for the command, easy 
enough.
   And how to use it? Well at least offer something like this:
help
[print major categories or some of the basic commands]
help all - print all command-names.
help [command] - print help for the specific command
or help category - print all the commands of the category and their meaning.
   As to category or command, in the syntax, that is completely up to your 
liking and judgement of the application. When you only have a few commands, 
help [command] will be easier and quickly done. When you have loads of 
commands, help [category] will do the trick as well. You don't need to supply 
the extra help [command] in addition. It's easy enough to navigate it.
   Yet beware of the small text-terminal. Usually it's set to 25-29 lines per 
screen. So if you have loads to print, use a pager (less). The (n)curses 
library offers a global variable called LINES, which should hold the number of 
lines, the screen has. The same goes for COLUMNS. As nothing will be done, 
while reading help, a simple system-call should be enough to call less. Write 
your help to a tempfile, best with the PID in its name and open it with less. 
When shutting down, just clean up all the files, with your name-scheme and 
PID, or clean up directly afterwards.
   Another question arose: How about capital letters on a braille display. A 
braille character in the computer world has 8 dots = 2**8 = 256 chars. So 
capitals are no problem. More problematic are unicode characters. I know, that 
one braille driver can handle them, not sure about the other one. But I can 
read normal German umlauts and the typical western European characters on my 
display. so that should be a matter of terminal and braille-driver 
configuration.
   I hope this wasn't too long for the info it contained and I hope, that it 
was clear. If something was fuzzy, just go ahead and bombard me with your 
questions.
   Kind regards
            Julien

--------
Music was my first love and it will be my last (John Miles)

======== FIND MY WEB-PROJECT AT: ========
http://ltsb.sourceforge.net
the Linux TextBased Studio guide
======= AND MY PERSONAL PAGES AT: =======
http://www.juliencoder.de