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 746488 - vte has accessibility issues that cause orca not to read incoming content in terminal emulators that use it
vte has accessibility issues that cause orca not to read incoming content in ...
Status: RESOLVED OBSOLETE
Product: vte
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: VTE Maintainers
VTE Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-03-19 23:04 UTC by kendell clark
Modified: 2021-06-10 15:01 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description kendell clark 2015-03-19 23:04:53 UTC
Steps to reproduce. First, activate orca. If you are in gnome, press alt+windows+s. If orca is not installed, install it. Open any terminal that uses vte, gnome-terminal and mate-terminal do, and there are others. Run any command that produces a lot of output. I frequently play mud (multi user dungeon) called alter aeon, but running a software update, running an rsync job, etc should do it. You'll notice that orca will start out reading the output, but will quickly start intermittently reading, skipping lines, cutting off the first letter of the text, etc. This is hard to track down exactly when this occurs but it will happen eventually. I can provide a debug log if needed.
Comment 1 Egmont Koblinger 2015-03-20 08:31:01 UTC
There were some a11y fixes recently, including something along the lines of cutting off the first letter. Could you please try the latest development version (0.39.92)?

What's the expected behavior in case the content changes quicker than it takes to read it out loud? Shall the display be intentionally delayed, potentially making e.g. a "cat hugefile" take hours/days instead of seconds? Or if skipping is okay, what should be the skipping strategy?
Comment 2 kendell clark 2015-03-20 20:27:52 UTC
To be honest, I'm not exactly sure. As long as orca can keep up with the output, and reads the output when it's supposed to, that's all that matters. I should've been more clear in my description. What I should've said was, when entering new text, EG typing keys, orca can sometimes fail to announce new characters, as well as new lines of output. I don't expect it to keep up with a rapidly scrolling terminal. That would require faster speech than I can understand. The issue is this. In alter aeon, when you move in a direction, open something, etc a line appears on the terminal. The issue is orca isn't reading new text that comes in sometimes. It just won't read new lines being added to the display. If that makes any sense.
Comment 3 kendell clark 2015-07-06 11:01:18 UTC
this has been partially solved in the latest vte stable release. However, orca still has trouble keeping up with new incoming text, occasionally cutting off the first character of new text. This usually, but not always, happens whenever the terminal scrolls,  causing orca to cut off the first character of the first line.
Comment 4 kendell clark 2015-11-05 13:54:00 UTC
just pinging this bug. This still occurs in vte3 0.42-1. It's worth nothing that this is far worse in vte2, which some gtk2 terminals, including guake and mate terminal, still use. Is vte2 still in active development and if so, could accessibility fixes be backported?
Comment 5 Egmont Koblinger 2015-11-05 15:30:04 UTC
(In reply to kendell clark from comment #4)

> Is vte2 still in active development

No, absolutely not. There was not a single commit since the latest 0.28.2 release (apart from translation updates).
Comment 6 kendell clark 2015-11-05 15:32:46 UTC
in that case, would it be possible to backport the current accessibility fixes to 0.28, even though there are still some bugs? Vte3 is much much better than vte2 at this.
Comment 7 Egmont Koblinger 2015-11-05 18:37:01 UTC
I have exactly zero interest in backporting any fixes to such an ancient version – and apparently no other Gnome(-Terminal) developer has any either.

Any minute spent on maintaining vte2 is wasted on something stupid, rather than wisely spent on porting the remaining terminal apps to Gtk+ 3, or anything other.

If we started maintaining vte2, there'd be about a hundred bugfixes to backport, a11y might be the most important for you, but according to typical demand it'd probably be somewhere near the end of the list.

If vte3's fixes are important for you, the best I can recommend to you is to upgrade to a terminal emulator based on vte3.
Comment 8 kendell clark 2015-11-06 03:32:55 UTC
good point. I guess the thing to do would be to fix the ramaining bugs, and then get terminal app devs to migrate over to gtk3 and vte3. Doesn't sound too difficult.
Comment 9 GNOME Infrastructure Team 2021-06-10 15:01:08 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vte/-/issues/2180.