Luca Saiu, le Thu 23 Apr 2015 09:31:55 +0200, a écrit : > I guess it's harder than just cat'ting a string to the Braille terminal > device file; if not, how do I find the device, querying brltty?
What you are looking for is brlapi. However, when will you precisely want to print the text? When the window switch actually happens, or when tabbing between applications before switching? If the latter, then brlapi should be fine: just connect, print what you want, and disconnect just before switching. If the former, one can't really know when to replace your output with orca's output. At best your write will be overwritten by orca' output of the just-focused widget. Now, as you expected I don't think stuffing screen reading in the window manager is the right way: how will the user enable/disable speech, how will he enable/disable braille? That's why we have a central screen reader to do all the screen reading, and not self-speaking applications. > the selected window title is shown, nicely rendered in > OpenGL, but the text is not available to the accessibility bus in any > way. In fact Compiz is not directly linked to ATK or even GTK, and > adding such huge dependencies is controversial. I rememember very well telling AT/SPI people a dozen years ago that even glib/gobject dependency would probably be too much... But actually there is no strict need for ATK/GTK, you can directly use dbus, and reimplement the IPCs yourself, it's a matter of exposing a textual role and its methods. ATK is just a way to factorize this code, AT/SPI doesn't impose using it. Samuel -- To UNSUBSCRIBE, email to debian-accessibility-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150423082626.gu4...@type.youpi.perso.aquilenet.fr
