[BRLTTY] mlterm

[Aura Kelloniemi]

Samuel Thibault <samuel.thibault at ens-lyon.org> writes:
 > 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.

Yes, you are right. I was thinking that BrlAPI already has authentication,
etc.

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

Is there a spec or a draft somewhere about this? It sounds very
interesting. AtSPI2's terminal interface (the way it is done now) has never
worked well.

But if this was done well, it would affect a lot of software -- orca, vte,
etc. VTE people at least haven't even fixed the accessibility bugs reported to
them already, so a question rises whether they would like to implement a new
feature at all. Of course these other applications and libraries would not
need to migrate to the new interface. Only if we did that new interface
well, they might consider -- orca at least, and orca might be able to affect
vte.

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

 > What benefit would it bring?

I would want the screen reading stuff to be separate from the communications
stuff. This would make the architecture cleaner. So thiss is about Unix
philosophy - small programs which all do a single thing, and do it well.

I would like to run a bare bones brailled (probably chrooted) and on top of
that screen readers, which would not need the same permissions as the braille
display communications daemon. If I happened to run a different screen reader
(or just an application with BrlAPI interface) than BRLTTY, it would save some
memory. This is because BRLTTY has a lot of code which is related to screen
reading and which would just waste my resources if I don't use BRLTTY's screen
reading capabilities. On an embedded system (where a Linux console or actually
any of the screens supported by brltty are not available) these savings to
memory usage might be really noticeable.

I could already kinda achieve this by building BRLTTY two times. First time I
would leave out all the speech and screen drivers, and then I would do another
build which would include all the screen and speech drivers, but would exclude
all braille drivers except ba.

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

True, but it might have taken them a lot more time to figure out how to add a
screen driver, they would have to engineer a protocol for transfering the
screen contents from mlterm to brltty, etc. Now they were able to only work
with codebase they already knew. I'm not saying this is I wish how it is, this
jsut explains it. If I was writing a screen reader I would probably do the
same as the mlterm folks. I probably would like to add new features to braille
rendering itself - for example I miss an ability to script the rendering
process with an embedded scripting language.

So let us be practical. We need a way for terminal emulators to send terminal
contents to brltty and a way for brltty to send commands to the emulator. We
probably would also need to support non-terminal widgets on the same go as all
terminal emulators which I know (that are running under X) have some kind of
menus. Does anybody feel like writing this new beast? I can help in
engineering (which might or might not be useful), but I don't have time to
dive into code.

Or are there other opinions? Are there people who feel like this kind of stuff
does not belong to BRLTTY at all?

-- 
Aura