Samuel Thibault <samuel.thiba...@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 _______________________________________________ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
