GNOME Bugzilla – Bug 427951
gnome-terminal Perk
Last modified: 2011-07-06 06:42:18 UTC
Our existing Perk runs terribly slowly. The strategy was: 1) Collection events 2) Re-order them so that they mimick other gtk text areas. 3) Let the basic Perks handle them as usual. This strategy relies on a window of time in which collection occurs. After that window has passed, the events are passed to the underlying Perks. The problem is that this window is fragile. Wait too long, and you get too many events or seem unresponsive. Wait too little, and you miss events and get into unknown states. The (unfortunate) solution is to rely on last key press information to determine what the user did to change the text. We should re-design the script under this strategy since it will be more deterministic and performant, but less easy to maintain. (User has to be first priority.)
Luiz, This is a long term bug fix that is going to require quite a bit of creativity and "hackish" code to resolve. Handle any smaller ones assigned to you first. We should look at the current GTerminalPerk together before you attempt to find a solution. Just let me know when you're ready to tackle this and we'll talk.
Created attachment 88213 [details] GTerminalPerk snapshot 5/15 first GTerminalPerk snapshot Basically, it creates a new task (HandleTerminalCaret) that chains around BasicSpeechPerk.HandleCaretChange task. It relies on key press to determine what is happening on the terminal to take action. The initial idea is to be able to stop any unwanted event from gnome-terminal by breaking the chain while still being able to use the BasicSpeechPerk. Minor problems, misbehaviors and terminal-specific stuff can be handle in the perk itself. This is what the current snapshot do. More to follow.
The current code is ugly, I know. Much can be improved, but right now I just want it to work right. As soon as I nailed this, I'll do a clean up in the code.
Created attachment 88416 [details] GTerminalPerk snapshot 5/18 second GTerminalPerk snapshot * After typing something, moving to the left does not speak the first char. Doing the same thing, but pressing backspace to del the last char outputs 'delete char' and not the expected 'backspace char'. Probably caret position problem. * Simple delete, move (both after the first char) and insert output from simple test cases sounds correct. The IO Monitor output is similar to gedit. * Output of simple commands (ex.: svn lsr) appear correct too. Still need to test in cases with more feedback from the terminal. * Did not test any kind of shell niceties (reverse search, tab completion) to check what would happen.
Getting there. It doesn't bother me how ugly this Perk gets. I just want it work! :) Here are two more problems I noticed: 1) After running 'ls', LSR starts to speak all the text, but immediately interrupts itself when the next text insert event happens and the prompt appears. An inhibitMayStop / mayStop combo is needed to prevent this situation. 2) Pressing Delete in the middle of a long string causes LSR to announce everything to the right of the delete location, not just the deleted char.
Created attachment 88767 [details] GTerminalPerk snapshot 5/24 FIXES: * terminal output - now a command output isn't interrupted by the next insert * the first backspace is now correctly announced as 'backspace', not as 'delete' * deleting a character in a middle of a long string no longer announce everything to the right, just the deleted char * added 'Home' and 'End' to the move_keys dictionary, pressing those keys now output the whole command line as it should * tested multi line commands (using '\'), announcement is OK. * cleaned up the code a bit, commented a bit more too. KNOWN ISSUES: * the first move after an insertion is not announced. BasicSpeechPerk.HandleCaretChange var 'changed' is set to 'True' after an insertion because it is expected to be reset to False in the subsequent move event. Find a way around this. * adding a character in the beginning or in the middle of long string causes LSR to announce everything to the right of the inserion point, not only the inserted char. This has to do with gnome-terminal funky behavior. I'll find a way around it. * other issues listed before (besides those fixed, of course) Comments and suggestions are welcome!
Looks like you're still making progress. I'm going to CC Larry on this bug since he was interested in the topic. Some other things to try/consider: * What happens if you run a tool like nano? * What happens when you scroll the buffer history up/down using shift-page up and shift-page down? Keep up the good work. Let me know if you think what you have should make it into 0.5.3 or should be delayed until 0.5.4. Compare it with the behavior of our existing GTerminalPerk. I suspect yours is better already. As for this problem: > * the first move after an insertion is not announced. > BasicSpeechPerk.HandleCaretChange var 'changed' is set to 'True' after an > insertion because it is expected to be reset to False in the subsequent move > event. Find a way around this. Are you returning False on the insert or the move from your Perk? An interesting thing to remember is that after you return False, the update() methods on other Perks lower in the stack continue to be called instead of their execute() methods. I believe BSP.HandleCaretChange does have an update method. Is it doing something with this flag? Should it be?
lsr (Linux Screen reader) development has been stalled and it has been unmaintained for a few years now. Maintainers don't have future development plan so i am closing the bugs as WONTFIX. Please feel free to reopen the bugs in future if anyone takes the responsibility for active development.