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

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
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Mon Apr 12 04:15:02 2010