[BRLTTY] BRLTTY and AT-SPI

[Samuel Thibault]

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