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