[BRLTTY] BRLTTY and AT-SPI

[Samuel Thibault]

Hello,

Aura Kelloniemi, on Fri 13 Nov 2015 11:18:01 +0200, wrote:
> There remains four issues: one that I reported already which can be
> reproduced with less and a long text file (just press down and right arrow
> keys in less repeatedly and watch how the braille display behaves).

This looks like a bug in VTE: here is what brltty gets when scrolling
over the GPL-3 licence text:

brltty: insert 66 from 1245
brltty: 'ou modify it: responsibilities to respect the freedom of others.
:'
brltty: caret move to 1311
brltty: delete 65 from 0
brltty: '  The GNU General Public License is a free, copyleft license for
'
brltty: insert 1 from 1246
brltty: ':'
brltty: caret move to 1247

So at some point the VTE widget inserted ':' without dropping the
previous one. No wonder brltty gets it wrong :)

This seems to happen when the additional line shown by less is an empty
line. With a mere file with only empty lines, brltty only gets these
events:

brltty: insert 1 from 23
brltty: ':'
brltty: delete 1 from 0
brltty: '
'

repeatedly.

> The other is a bug in BRLTTY's BrlAPI braille driver. With it, I get double
> cursor. The cursor is shown both by BRLTTY (which has its own cursor drawing
> logic), but also by BrlAPI.

I hadn't initially understood what you meant by "double cursor". So you
don't mean that you have two cursors shown on different cells, but two
cursors shown on the same cell, which can be seen by making them look
different, right?

I guess I understand why: the brlapi driver gets told to render text,
dots (with the cursor drawn by brltty), and the cursor position. It thus
passes that through brlapi. The second brltty then draws the text (with
the cursor position), dots (and draws the cursor there again).

We do prefer to have the brlapi driver pass the cursor position to the
second brltty, for displays which can show it.

Actually, we didn't plan brlapi clients to draw the cursor, so the bug
would be that the first brltty draws the cursor. Dave, could there be
a way for braille drivers to tell the core "I will handle drawing the
cursor as dots"? It could make sense for instance if the device has
another way to represent the cursor than braille dots (which is the case
here in the brlapi driver).

> The first is yet another bug with trailing whitespace:
> In a text editor the cursor position is not shown correctly,

Indeed, it should be easy for VTE people to reproduce it.

Samuel