Re: The new text-mode menu and the cursor in -nw mode

[Mario Lang <mlang@delysid.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Mario Lang <mlang@delysid.org>
>> Date: Mon, 28 Apr 2014 20:14:37 +0200
>> 
>> > Next, what happens when some sub-menu is selected?  When the user
>> > does this, we redraw large portions of the screen (to remove the old
>> > menu and display the new one), and each screen line that is partially
>> > or fully redrawn causes cursor motion -- will this cause those
>> > portions that are redrawn to be read, and if so, is that OK?
>> 
>> It would be ideal to only reposition the cursor when the drawing has
>> been complete.
>
> I don't think we can do that.  I'm not an expert, but I think text
> terminals must move the cursor to where they are going to write stuff,
> before actually writing it.

Yes, sorry, I was unclear on that.  I know what you describe.  I ment to
say: After the screen has been drawn, set the cursor to the beginning of
the highlighted area.

>> > Finally, what exactly is read by the screen reader, given a cursor
>> > position?  That is, how does the reader know when to stop reading
>> > stuff off the screen?  I'm asking this because the TTY menus overlay
>> > the buffer text at some arbitrary place, so where the menu item ends,
>> > there's some random text, which typically starts in the middle of a
>> > word.  If the reader will read that, you will hear a terrible
>> > gibberish.
>> 
>> I am a braille user.  A braille display typically consists of 40 or 80
>> characters.  When the hardware cursor position changes, my braille
>> display is typically updated around that cursor position.  As a braille
>> user, I can make sense of text that is mixed, i.e., I can understand
>> that a part of the text is related to the menu item, and the rest is
>> related to the text that was displayed before the menu overlayed this
>> area of the screen.
>
> The menu is displayed in different colors.  But since you say that
> colors are "lost in translation", I wonder whether it is indeed as
> easy as you describe to understand where the menu item ends and the
> overlaid text begins.

Trust me, it is, this is something that blind users have to cope with,
and we know how to do that.

>> However, as mention in this thread, what is important to both
>> groups, is that the hardware cursor position is update if the
>> currently "highlighted" area of the screen changes, so that the
>> screen reader can "follow" the hightlight around on the screen.
>
> That's exactly what bothers me: updating a menu might, and generally
> will, change more than one place on the screen.  As a trivial example,
> moving to the next menu item will redraw both the one which was
> highlighted before and the one that is to be highlighted now.  Screen
> readers will probably read both (and the help echo in between them),
> and I'm not sure the user will understand what is going on, not
> without some training.

I am not really sure about speech based screen readers, but some have
ways to cope with very fast screen updates, and present the changes in a
"meaningful" way.  All I know, as a braille user, is that the hardware
cursor position is essential to indicate the highlighted area.  Screen
update ordering is totally irrelevant to me, since the screen updates
happen way to fast to actually "see" them.  However, what I need is the
hardware cursor on the highlighted item, such that my screen reader
shows the text "around" the highlight area, instead of going stuck in
the middle of the currently active window.

-- 
CYa,
  ⡍⠁⠗⠊⠕ | Debian Developer <URL:http://debian.org/>
  .''`. | Get my public key via finger mlang/key@db.debian.org
 : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
 `. `'
   `-      <URL:http://delysid.org/>  <URL:http://www.staff.tugraz.at/mlang/>