Hi, and thank you for the quick reply! Samuel Thibault <[email protected]> writes:
> Aura Kelloniemi, le Fri 28 Aug 2015 23:55:53 +0300, a écrit : >> - BRLTTY does not correctly detect the terminal size (it tries to guess it by >> examining line lengths, but this fails). Because of this the cursor is >> often >> out of BRLTTY's knowledge. > Could you provide reproducible test cases? Sure, my .xinitrc looks like this: ### BEGIN .xinitrc: #!/bin/bash for f in /etc/X11/xinit/xinitrc.d/*; do [ -x "$f" ] && . "$f" done unset f export GTK_MODULES=gail:atk-bridge export SAL_USE_VCLPLUGIN="gtk" export GNOME_ACCESSIBILITY=2 /usr/bin/xbrlapi & /usr/bin/orca & sleep 2 # THis is annoying, but necessary /usr/bin/brltty -b ba -x a2 -ne -l 7 > /tmp/brl 2>&1 & /usr/bin/lxterminal & exec lxsession ### END .xinitrc Now when lxde starts, I sometimes need to press ALT-TAB so that BRLTTY notices which window is active. Then the display shows my bash prompt, because that's the only thing on the terminal screen. But the cursor is not shown, because its position is the length of the terminal text string (acquired from D-Bus by BRLTTY) plus one. So if I now type any leter or space, and then backspace or arrow left, the cursor appears, because its position is now between 0 and the terminal text string length (esclusive). >> - Sometimes BRLTTY shows line-feed (\r) characters instead of breaking lines I can't reproduce this right now, but it happens often. I will report this when I notice it. >> - Sometimes BRLTTY shows incorrect text (text that has already disappeared >> from the visual window) > That may be bugs in the terminal itself actually. Again, reproducible > testcase would be useful, otherwise I don't really know where to look > at. In lxterminal I run emacs -nw, and then almost any BRLTTY command will display something that is not on the screen, including previous commands typed, etc. Running the HOME command returns BRLTTY to display expected thigs again. This seems to be terminal-dependent though, because this problem does not appear to be present in roxterm. >> - BRLTTY and Orca are having a hard time deciding which one has the control >> of >> the braille display - for example Orca should take precedence in menus, >> while BRLTTY should display the actual terminal widget. > You can tell brltty which widgets it should take control of with > -X type=terminal Sometimes this does not work, and Orca takes over the braille display entirely, or then Orca's braille output is lost completely. >> - BRLTTY does not support copy/paste > I'm surprised, this should already be working, either from the brltty > running the linux driver, or through xbrlapi. >> or cursor routing in its AT-SPI driver > I'm surprised, IIRC cursor routing is independent from the screen reader > actually, it's the core which tries to move the cursor. Yes, but cursor movement and copy/paste require support from the driver - the driver must be able to emulate key presses, and this apparently is not supported by the AT-SPI2 driver. >> - Immediate key presses (those defined in key table with !) don't work in >> brlapi - commands activated by immediate key presses are only run every >> second time the key is pressed. > I don't know what immediate key presses are. That probably explains why > they're not working correctly. From http://mielke.cc/brltty/doc/Manual-BRLTTY/English/BRLTTY-6.html#key-table-bind: "The keys may be pressed in any order, with the exception that if the final key name is prefixed with an exclamation point then it must be pressed last. The exclamation point prefix means that the command is executed as soon as that key is pressed. If not used, the command is executed as soon as any of the keys is released." I also should add to my problem list the following: - When using the AT-SPI2 driver there is no cursor tracking. For some reason the display does not follow the cursor, even though cursor tracking is on. >> If there is going to be some sort of AT-SPI2 driver development, I >> think that the driver should use the library interface to AT-SPI, instead of >> directly calling the D-Bus methods - this way the code will probably look >> better and it will be more tolerant to API changes. > Except that there is no such thing any more. With AT-SPI1 we could use > one, but for AT-SPI2 only the server part really has bindings. Isn't libatspi just this. It is part of at-spi2-core package. From it's README: "[libatspi is a] C library for use by ATs [(Accessibility Service providers)]. Wraps the various D-Bus calls, provides an interface for listening to events, and caches some information about accessible objects. Also contains some functions used by at-spi2-atk." This library is also used by the at-spi Python bindings used by Orca. > X window is mostly out of the picture actually, Glib shouldn't be > involved much, so it's more about the brltty codebase, AT-SPI and D-Bus, > you're welcome for questions etc. in any case. Thank you! I try to grasp the workings of at-spi2, but it is not at all well documented. -- 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://mielke.cc/mailman/listinfo/brltty
