[BRLTTY] mlterm

[Aura Kelloniemi]

Samuel Thibault <samuel.thibault at ens-lyon.org> writes:
 > So they reimplemented a screen reader within mlterm, and exposed the
 > content through brlapi.  That's not really the best way to do this:
 > it means all the navigation features that brltty provides are either
 > reimplemented in mlterm (thus duplicate code), or missing.

 > There should rather be a standard way for fb terms to expose their
 > content to brltty, similarly to how the kernel exposes the VT content
 > through /dev/vcs*

I think this is a good start. I at least have been stuck with the almost
deprecated and horribly broken Linux consoles for almost 20 years now.

But yes, a better interface would be great. The best way probably would be
through BrlAPI - brltty would just support new functions for clients to
provide virtual screen contents and ways to update it. This of course would be
slower than shared memory, but this would work across the internet too. This
interface should be designed such that it will be possible to extend it.

And it would be great if BRLTTY could also upgrade its view about terminal
contens. Currently for brltty there is only text with colour attributes.
Terminals support other attributes as well - bold, inverse video, underlining,
etc. BRLTTY could support these as well.

My wish would actually be that all screen driver modules were converted to
BrlAPI clients. Maybe BRLTTY itself could be a BrlAPI client which would
communicate with the lowest level braille-daemon which only talks to the
hardware devices and with clients providing raw content to be displayed.

Great... BRLTTY could do this and that, however, there is one question though.
Is there anybody who has the time, skills and interest to implement any of
this? My gut feeling is that mlterm has been reimplementing BRLTTY's features
exactly because of lack of interface (and people who are familiar with
BRLTTY's codebase). So maybe this is the way to do it for now.

-- 
Aura