[BRLTTY] Interfacing with terminal emulators (was: Re: Broken colour names)

[Aura Kelloniemi]

Samuel Thibault <samuel.thibault at ens-lyon.org> writes:

 > Mario Lang, on Tue 17 Nov 2015 22:11:15 +0100, wrote:
>> When we originally planned to do it via SHM, D-Bus was not around.
>> Is SHM still the best option?
[--]
>> The libraries are a convenience, but it is perfectly
>> possible to code a standalone AT-SPI client just by using a D-Bus
>> binding.

 > Yes, but even a D-Bus binding is quite tedious to implement, compared to
 > just exposing the screen content in a SHM.

I'm not opting for D-bus, because of its heavyness, but I raise one concern
with simple communication channels with terminal emulators. This may have
large impact on the "accessibility stack" we are using.

User-space terminal emulators are likely to implement some user interface for
configuring the terminal preferences on the fly. I'm not very willing to use a
terminal which in some operations relies on such an interface, if that
interface is not accessible. If we want to design a general-purpose interface
for communicating with terminals, it may turn out that it is quite complex,
and we need to work with many kinds of UI controls. Also, the communication
needs to be bidirectional - BRLTTY needs to be able to press buttons and enter
text to input fields, if we want to support wide use of braille display
control knobs.

Hopefully if non-X terminal emulators incorporate a menu or dialog system,
they base it on the TTY interface, so that BRLTTY does not need to know
whether it is displaying a text-editor's frame or terminal emulator's
configuration menu. But at least X terminals have chosen not to do it text
way, but use graphical widgets.

BRLTTY already supports a wide variety of UI elements on the Android target,
perhaps support for rendering and working with UI elements is needed in the
core at some point.

Personally I want the interface, whatever it is going to be, to be simple and
fast. I want it to run on an embedded system. I really don't like the idea
that being able to log in would require glib, D-bus, AT-SPI, fontconfig, python, etc.
And all of these should work "out of the box" so that I can read fsck error
messages with my braille display, even if the file system that is broken is my
rootfs. But still it would be nice if I could use a light-weight scripting
language to configure BRLTTY and to be able to write some braille rendering
filters with it - Lua could be a nice choice.

One thing that I have always liked in BRLTTY very much is its modularity. I
can disable most of the features I don't need at compile time to get a smaller
binary. Concerning the future development of BRLTTY, I wish that BRLTTY could
separate the BRL and TTY parts. This could mean a separate brailled which
would implement braille/speech drivers as plugins and an enhanced brlapi
server. BRLTTY would then become a Brlapi client, having screen and other
terminal I/O drivers as plugins.

-- 
Aura