After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 397668 - Blank lines are not announced as blank lines in gnome-terminal
Blank lines are not announced as blank lines in gnome-terminal
Status: RESOLVED FIXED
Product: orca
Classification: Applications
Component: general
2.17.x
Other All
: Normal minor
: FUTURE
Assigned To: Patrick Wade
Orca Maintainers
post-3.0
: 600101 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-01-17 16:10 UTC by Willie Walker
Modified: 2011-01-08 04:10 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Partial patch to work around the problem -- needs work. (2.12 KB, patch)
2007-01-18 21:59 UTC, Rich Burridge
needs-work Details | Review

Description Willie Walker 2007-01-17 16:10:49 UTC
This may be a gnome-terminal accessibility implementation problem.   Here's what you need to do to reproduce this problem (it's what I did on Ubuntu Edgy with Orca revision 1931 from SVN):

1) Run orca
2) Open a gnome-terminal and run 'vi' in it. Enter several blank lines
3) Arrow up and down over the blank lines

Orca doesn't say anything.  If you look at the debug of Orca, you will see the following:

sayLine: line=<                                                                                >, len=80, start=81, caret=81, speakBlankLines=True
SPEECH OUTPUT: '                                                                                '

This seems to indicate the at-spi implementation of gnome-terminal is telling us a line is all spaces, when in fact it is not.
Comment 1 Rich Burridge 2007-01-18 21:59:39 UTC
Created attachment 80653 [details] [review]
Partial patch to work around the problem -- needs work.

This should probably be fixed in vte, but I looked at working
around it by customizing the gnome-terminal script. The problem
here (especially if the user is in vi), is that they might have
moved to a different line via the "j" or "k" keys, not the up
or down arrow keys.

What we really need to be able to do in the new sub-classed
sayLine() routine, is determine what the type of the last accessibilty
event is, or some other indication that we have changed lines within
the terminal window. I'm not sure that is doable.
Comment 2 Rich Burridge 2007-03-08 19:45:06 UTC
Adding Chris Wilson to the cc: line.

If I uncomment the debug statement in Orca's sayLine() routine in default.py,
I see that we are still getting:

sayLine: line=<                                                                                >, len=80, start=243, caret=243, speakBlankLines=True
SPEECH OUTPUT: '                                                                                '
BRAILLE LINE:  'gnome-terminal richb@richb-desktop: ~   richb@richb-desktop: ~ Terminal                                                                                '

In other words, a "blank line" inside fnome-terminal (and also vte)
is being sent to us as a line 80 characters in length, and mostly composed
of spaces.

Chris, can/should this be fixed in the vte code? It's hard to program
around it in Orca (see comment #1 above).
Comment 3 Chris Wilson 2007-03-08 20:13:15 UTC
It would appear that changing vteaccess from using vte_terminal_get_text_include_trailing_spaces() to vte_terminal_get_text() would be adequate - except for bug 141148.

I'll read through the history and see why empty cells are returned to vteaccess as  spaces.
Comment 4 Rich Burridge 2007-03-08 21:07:01 UTC
Thanks Chris!
Comment 5 Rich Burridge 2007-03-29 21:15:22 UTC
Chris, an update on this bug? Thanks.
Comment 6 Rich Burridge 2007-05-14 20:18:00 UTC
Chris, any update on this bug? Thanks.
Comment 7 Willie Walker 2009-11-04 13:33:27 UTC
*** Bug 600101 has been marked as a duplicate of this bug. ***
Comment 8 Trevor Saunders (IRC: tbsaunde) 2011-01-08 04:10:54 UTC
This works for me with gnome-terminal 2.30.2 so I'm closing this bug