GNOME Bugzilla – Bug 142772
gnopernicus does not read gnome-terminal output on the fly
Last modified: 2004-12-22 21:47:04 UTC
-launch gnopernicus -launch gnome-terminal -type 'ls' .gnopernicus does not read the newly displayed text. the only way to read this appears to be using the 'read whole window' function. Even then this is a slow and tedious method. Am I missing something?
This is the normal behaviour for gnopernicus. If a command generates a lot of output, that output is reported by at-spi as many "text-insert" events. Because of that, gnopernicus cannot distingues between "text-insert" events as result of a single user action and same situation, when output is result of many user actions. Because of that, this bug will not be fixed in gnopernicus.
If not then please reassign to the component which can fix this, it can't just be dropped.
I think the answer here is to move to a new event handling scheme (much discussed over the past month or so), where all output is queued except when clearly generated from a user action, in which case all output is interrupted. I think this should therefore remain a Gnopernicus bug.
Will not fix for Gnopernicus 1.0. The ideal behavior is much more complex and sophisticated to implement. For now the user will simply use screen review.
David: Marc confirmed that it's normal for the default mode of speech for terminals _not_ to speak all output; the user normally has to use some sort of review (or use some sort of virtual text caret) in order to review the text that's been output. There are some gnopernicus (and gnome-terminal) RFEs that probably should be filed, longer-term, but the current default is probably correct for 1.0.
*** Bug 154776 has been marked as a duplicate of this bug. ***