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