[BRLTTY] mlterm

[Samuel Thibault]

Aura Kelloniemi, on jeu. 25 janv. 2018 10:23:46 +0200, wrote:
> But yes, a better interface would be great. The best way probably would be
> through BrlAPI

No, because that assumes braille. There can be speech-only screen
readers too, and whatnot. Also, there is nothing related with brlapi,
actually :) So better have another client/server mechanism.

> - 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.

Well, actually it already exists, it's called AT-SPI2. It's based on
dbus and brings quite a few abstractions. ATM it proposes a Text-based
interface, which means insertion/suppression events which make it quite
complex. A Terminal-based interface was designed, but never actually
implemented. We could use that.

> My wish would actually be that all screen driver modules were converted to
> BrlAPI clients.

What benefit would it bring?

> 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.

It can already act as such: it's the ba driver.

> 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?

That's the problem indeed.

> 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.

Well, the time it took to reimplement all of that could have been used
to implement an interface instead...

Samuel