[BRLTTY] brltty "keyboard braille device" support (and a few more things)

[Dave Mielke]

[quoted lines by Klaus Knopper on 2007/01/25 at 08:28 +0100]

>The main difference would be using the keyboard instead of a braille
>device, hence the idea of just adding a "keyboard braille device" driver
>with no output function, but input keys, which then can be used
>standalone, or together with a real braille device. 

If there isn't any output device, how would the user know what he's doing? 
Perhaps I'm just slow at catching on to a new concept, but what use would it be
to have navigation functions which have no way of giving any user feedback?

>Mario told me that
>the new versions of brlty are not depending on a device poll loop
>anymore, so the screenreader is more or less independent from a real
>braille device already.

That's essentially true, although none of the drivers have been converted yet. 
Monitoring the keyboard for asynchronous events, however, is easy to add.

>> It'd be nice
>> to use a scheme which wouldn't interfere with Speakup's bindings.
>
>Is speakup needed for brlttys functioning? In our project, we would like
>to use festival (because of quality), espeak (because of the small
>footprint) with or without speech-dispatcher.

I certainly wouldn't want to do anytghing which prevents brltty and speakup
from coexisting since I believe in giving users the freedom to mix and match as
they themselves would prefer. If a user would like to use brltty and speakup
together then he should be able to do so.

>Right, and this doesn't work in sbl either. even if using "screen"
>locally, the real program profile isn't autodetected anymore. In this
>case, there are keyboard hotkeys that allow you to switch from the
>"bash" profile to "mutt", "elinks" or similar.

Application-specific profiles are an interesting idea, but are they really all
that useful? Maybe I'm just used to working for so long without them. In any
event, I have a hard time getting interested in features which only work in
certain cases. Perhaps they could be made to work better if, rather than asking
the system what the foreground program is, they pattern-match the screen
content/highlighting for application-specific appearances.

>Just having hotkeys that allow you to change pitch and speed via the
>keyboard would be fine, hough sbl also supports this in the profile
>selection, so if you start a mail program, the sound sesstings can be
>different from those in plain bash.

I understand the concept. Adding functions for more properties, e.g. language,
is easy. Application profiles, as mentioned above, are a separate issue. If we
have them then, of course, they'd be able to establish settings.

>Would it be helpful if I send you my current sbl source so you can have
>a look at it, or would you rather like to just point me to the right
>place to start implementing a keyboard driver in the brltty source?

I don't think a keyboard driver is the right way to do it. A keyboard monitor
would be much better. I shall think about it for a bit.

-- 
Dave Mielke           | 2213 Fox Crescent | I believe that the Bible is the
Phone: 1-613-726-0014 | Ottawa, Ontario   | Word of God. Please contact me
EMail: dave at mielke.cc | Canada  K2A 1H7   | if you're concerned about Hell.
http://FamilyRadio.com/                   | http://Mielke.cc/bible/