Sébastien Sablé <sable users sourceforge net> writes: > I have been working for some time on a project called libbraille, which > I think could be useful for kde and gnome accessibility. > > Libbraille is a shared library which makes it possible to easily access > Braille displays and terminals. It provides a simple API to write text > on the Braille display, directly draw Braille dots, or get the value of > pressed keys. It is compatible with a wide range of Braille displays and > can autodetect some of them. "wide range" is a very stretchable term indeed. If I look at the braille display hardware I personally use at work and at home: * HandyTech Braille Star: libbraille only appears to support the serial port of HandyTech displays, no support for USB or the recently installed bluetooth connectivity. On my laptop, I have no serial port, so the display would be completely unusable without a USB-to-serial adapter with only libbraille. No support for the external keyboard either. Telesensory Inc. PowerBraille 40/80: I couldn't find any driver in libbraille for those displays at all. So, of the three available displays I have, only one is very partially supported by libbraille. That doesn't look too good to me, and I am a bit afraid of such a driver base being adopted in any major desktop project as the primary braille library. > Some features include: > * support for serial and USB displays BRLTTY supports the following display models via USB: Alva Satellite, Freedom Scientific displays, Papenmeier EL 40 Slimline, HandyTech Braille Star/Braillino and the Tiemand Voyager. From what I can see, you currently only seem to support the Alva satellite displays via USB. > * usable from C or as a Python module or as a Java extension libbrlapi is also usable from C, and bindings to other languages should be reasonably simple to implement. In fact, I wrote a binding for GUILE a year ago in about 2 hours IIRC. > * distributed under the LGPL Free Software Licence BRLTTY's BrlAPI is also distributed under the terms of the LGPL, at least all the code required for the client side library is LGPL. > * portable (linux, win32, MacOS X, FreeBSD, Solaris and probably other > unix systems) BRLTTY has been ported to Solaris, HP-UX, OpenBSD, FreeBSD and NetBSD. > * provides a virtual graphical terminal so that developers without a > Braille display can develop and test their application with a (Fake) > Braille display Such a "fake" display has just been added to BRLTTY in the development repository, actually two: One for TTY's, and one for XWindows. BRLTTY 3.5 (the last release) includes a "Virtual" driver which allows one to write his own client (freedom of choice of toolkit). > * supports blocking or timeout mode for reading Braille keys Same for BrlAPI. > * usable directly from Mozilla in JavaScript as an XPCOM component > In the end, I am more than glad to see yet another free software developer working on Braille terminal issues, but I am very sad about yet another fork. I think it can not be good for the user-base if we have several driver code bases with varying quality. Note that yet another issue is sharing devices between several applications. You were criticizing the fact that BRLTTY is a daemon and does console screen reading by default in some other mail. This is actually a big advantage to some, since it allows for different screen readers to cooperate nicely without running into device locking problems. If I configure Gnopernicus for instance to use BrlAPI as braille output backend, I can switch between text and graphical consoles back and forth without any problems. As long as a text console is current, BRLTTY does its screen reading job, and as soon as my X Window console is current, Gnopernicus gets to write to the display. I think this is even more important if we consider that KDE is entering the picture in the future. Yet another important feature of BRLTTY is that it does not require any components from the /usr filesystem hierarchy, making it possible to run very early in the system boot process when /usr is not mounted yet. This is vital to enable blind users to administer their systems as independently as possible. Since libbrlapi lives in /lib, BrlAPI clients can inherit this property from BRLTTY. -- CYa, Mario
Attachment:
pgp1gFTMNWE30.pgp
Description: PGP signature