Hello, 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? > - Sometimes BRLTTY shows line-feed (\r) characters instead of breaking lines > - 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. > - BRLTTY does not support showing screen attributes in AT-SPI terminals Mmm, that would be quite involved, but feasible indeed. > - 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 > - 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. > - 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. > - brlapi also does not support showing thext in the status cells of the > display (this is not a problem for me though, because I don't have a display > with dedicated status cells any more). Indeed. The problem with status cells is that they are really not standard across models, so it's hard to define a sensible API for that. > 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. > I myself have some programming skills, and I'm willing to help. However, I > have no experience working with BRLTTY codbase, X windows APIs, AT-SPI, > D-Bus or even GLib, so I would need some help in getting started. 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. Samuel _______________________________________________ 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
