GNOME Bugzilla – Bug 667283
Refactor regressions - Keyecho
Last modified: 2012-02-03 23:03:26 UTC
From Dave on the Orca list: I have alphanumeric and punctuation keys set to echo. When in a Mozilla app or Pidgin, if I use an orca command, like 'orca+t', for instance, Orca now echos the keypress, then does the bound action. In the terminal, Orca just does the requested thing, e. g. telling the time. ~~~~~~~~~~~~~~~~ From Attila on the Orca list: I found some minor issues this modification related, with need confirming. 1. I using laptop layout. When I using any Orca command, Orca now spokening the Orca command letter part. For example, if I doing speech state toggle on/off, Orca spokening capital s before doing the proper command. Prewious I think this issue is not happened. 2. Whit laptop layout, if I press Orca modifier+backspace keystroke and pass the capslock key press, Orca spokening partialy translated the capslock state change, and spokening wrong capslock state change if the capslock state is changed off. Spokening translated the capslock key name, and spokening always on status (this text part are untranslated. Example output: "nagybetű zár on" Nagybetű zár text meaning english the caps lock keyname translated output part.
This commit should fix Dave's reported issue, which appears to be the same as Attila's issue #1. http://git.gnome.org/browse/orca/commit/?id=9f2e726c15d34d33c6ef5df7320a0a44295a76ac
With respect to partially translated capslock state, that was due to my failing to include input_event.py in the POTFILES.in. Sorry about that! When I corrected that mistake, Hungarian still said 'on'. I then looked at the hu.po and it said the strings were 'fuzzy'. I'm guessing that is because the strings now have qualifiers ('locking key state'). After all "on" and "off" without a qualifier seems like asking for a wrong translation. Anyhoo, as a test, I removed the 'fuzzy' indicators, rebuilt, and Orca now speaks the 'on' as translated. So I committed the POTFILES.in change. I guess translators have a tiny bit of work to do on their end now. So of the current regressions that just leaves not saying 'off'. But when I looked at both the resulting keypresses and the keyboard light, Orca was actually *speaking* the right state; it's the state that doesn't seem to be changing. So... back to the code with me. :)
Don't speak state of CapsLock when it is serving as the Orca modifier http://git.gnome.org/browse/orca/commit/?id=25061a104410a044c95677bff491d6f2d7b427e6 Be sure we allow Caps Lock to be toggled when it is the Orca modifier and bypass mode is enabled http://git.gnome.org/browse/orca/commit/?id=3285c1fe5022924b68e10c57a246b82d8b7e02cb I believe I have addressed all of the issues reported above. Please test and report any other regressions (1 per comment please) in this bug.
It appears to me that the capslock key is having no effect at all except for being the Orca modifier. I went into a gnome terminal and toggled the caps lock key there and I heard no speech echoed and when I subsequently typed other keys while in the terminal that there was no pitch change in echoed text; makes me think the actual caps lock status is *NOT* changing. I just goggled caps lock key. I just now turned caps lock off. Notice that the actual capitalization did not change. Oh yes, this key actual works because when I press it down and hold, Orca's laptop layout functionality does work.
Steve, is this with the latest master?
Yes, I built the package on the evening of 01/05/2012 and completed these tests right after that. I Have the first checkbox for echoing keystrokes and at this time, I have also checked the echoing of characters as typed. I do not have modifier keys like shift, ctrl and alt spoken; nor do I speak function or navigation keys. Also at some point during this immediate cycle possibly with a day or two earlier's version, I changed to desktop layout briefly enough to see that the capslock key would then speak and it indeed spoke the caps status. So it's just laptop layout where I experience this problem.
Pulled Midnight, EST today. Now, there is no key echo, in any app, but the terminal, even though I have not changed my key echo values in preferences. Am using laptop layout.
(In reply to comment #7) > Pulled Midnight, EST today. Now, there is no key echo, in any app, but the > terminal, even though I have not changed my key echo values in preferences. Am > using laptop layout. Weird. Because I could reproduce the problem you described, and now things are working as expected for me. So I'd like to try with your preferences. Could you please attach your user-settings.conf? Thanks!
Below is the contents of my 'user-settings.conf', as requested. HTH { "pronunciations": {}, "keybindings": {}, "profiles": { "default": { "orcaModifierKeys": [ "Caps_Lock" ], "pronunciations": {}, "enableMagCursor": true, "enableMagCrossHair": true, "magEdgeMargin": 0, "keyboardLayout": 2, "brailleContractionTable": "/usr/share/liblouis/tables/en-us-comp6.ctb", "enableMagLiveUpdating": true, "magPointerFollowsFocus": false, "magTextTrackingMode": 2, "magZoomerBorderSize": 1, "magContrastLevelGreen": 0, "magContrastLevelBlue": 0, "magPointerFollowsZoomer": true, "magCursorColor": "#000000", "magCrossHairSize": 16, "magHideCursor": false, "magZoomerType": 0, "enableMagZoomerColorInversion": false, "magCursorSize": 32, "magContrastLevelRed": 0, "magSmoothingMode": 0, "magBrightnessLevelRed": 0, "magZoomerLeft": 840, "keybindings": {}, "enableModifierKeys": false, "enableLockingKeys": false, "profile": [ "Default", "default" ], "magBrightnessLevelBlue": 0, "enableMagZoomerBorder": false, "magContrastLevel": 0, "magControlTrackingMode": 2, "enableActionKeys": false, "enableMagnifier": false, "magBrightnessLevelGreen": 0, "magMouseTrackingMode": 0, "magZoomerBottom": 1050, "voices": { "default": { "average-pitch": 5.0, "rate": 100.0, "family": { "locale": "en", "name": "english-us" } }, "uppercase": { "average-pitch": 10.0 }, "system": { "established": false }, "hyperlink": { "established": false } }, "magZoomerRight": 1680, "enableFunctionKeys": false, "brailleEOLIndicator": " ", "magTargetDisplay": "", "magZoomFactor": 4.0, "magZoomerTop": 0, "magCrossHairColor": "#000000", "magSourceDisplay": "", "magZoomerBorderColor": "#000000", "speechServerInfo": [ "espeak", "espeak" ], "magColorFilteringMode": 0, "enableMagCursorExplicitSize": false, "speechServerFactory": "orca.speechdispatcherfactory", "magBrightnessLevel": 0, "enableMagCrossHairClip": false } }, "general": { "speakCellHeaders": true, "magEdgeMargin": 0, "brailleContractionTable": "", "magPointerFollowsFocus": false, "magTextTrackingMode": 2, "magZoomerBorderSize": 1, "brailleAlignmentStyle": 0, "enableEchoByWord": false, "enableMagZoomerColorInversion": false, "magCursorSize": 32, "magSmoothingMode": 0, "magZoomerLeft": 840, "showMainWindow": true, "sayAllStyle": 1, "brailleSelectorIndicator": 192, "presentDateFormat": "%x", "magContrastLevel": 0, "magMouseTrackingMode": 0, "speakCellSpan": true, "progressBarUpdateInterval": 10, "speakCellCoordinates": true, "enablePauseBreaks": true, "brailleEOLIndicator": " ", "verbalizePunctuationStyle": 1, "progressBarVerbosity": 1, "enableSpeech": true, "enableBraille": false, "mouseDwellDelay": 0, "enableBrailleGrouping": false, "readTableCellRow": true, "speechServerFactory": "speechdispatcherfactory", "textAttributesBrailleIndicator": 0, "enableMagCursorExplicitSize": false, "messageVerbosityLevel": 1, "enableMagLiveUpdating": true, "enableSpeechIndentation": false, "enableKeyEcho": true, "magHideCursor": false, "magZoomerBorderColor": "#000000", "magBrightnessLevelRed": 0, "enableMagnifier": false, "magZoomFactor": 4.0, "activeProfile": [ "Default", "default" ], "enableMagZoomerBorder": false, "flashVerbosityLevel": 1, "enableFlashMessages": true, "speechServerInfo": null, "presentToolTips": false, "flashIsPersistent": false, "brailleRequiredStateString": "required", "firstStart": false, "largeObjectTextLength": 75, "enableEchoBySentence": false, "magContrastLevelBlue": 0, "magContrastLevelRed": 0, "enableContractedBraille": false, "orcaModifierKeys": [ "Insert", "KP_Insert" ], "enableMagCursor": true, "speechRequiredStateString": "required", "chatAnnounceBuddyTyping": false, "quitOrcaNoConfirmation": false, "magPointerFollowsZoomer": true, "magCursorColor": "#000000", "enablePositionSpeaking": false, "magZoomerType": 0, "onlySpeakDisplayedText": false, "enableProgressBarUpdates": true, "wrappedStructuralNavigation": true, "chatRoomHistories": false, "brailleVerbosityLevel": 1, "enableFunctionKeys": true, "skipBlankCells": false, "enableModifierKeys": true, "magCrossHairColor": "#000000", "enableTutorialMessages": false, "enableActionKeys": true, "speakBlankLines": true, "magColorFilteringMode": 0, "magZoomerRight": 1680, "keyboardLayout": 1, "magTargetDisplay": "", "disableBrailleEOL": false, "magZoomerTop": 0, "magSourceDisplay": "", "enableDiacriticalKeys": false, "enableMnemonicSpeaking": false, "magContrastLevelGreen": 0, "speechVerbosityLevel": 1, "enableMagCrossHair": true, "enableBrailleMonitor": false, "voices": { "default": { "established": false }, "uppercase": { "average-pitch": 5.6 }, "system": { "established": false }, "hyperlink": { "established": false } }, "enabledBrailledTextAttributes": "size:; family-name:; weight:400; indent:0; underline:none; strikethrough:false; justification:left; style:normal; text-spelling:none;", "brailleFlashTime": 5000, "magCrossHairSize": 16, "enableMouseReview": false, "enableNavigationKeys": false, "magBrightnessLevelGreen": 0, "chatSpeakRoomName": false, "profile": [ "Default", "default" ], "startingProfile": [ "Default", "default" ], "enableLockingKeys": true, "speakMultiCaseStringsAsWords": false, "brailleRolenameStyle": 1, "brailleLinkIndicator": 192, "enableEchoByCharacter": false, "magBrightnessLevelBlue": 0, "enableBrailleContext": true, "magControlTrackingMode": 2, "magZoomerBottom": 1050, "enablePrintableKeys": true, "enabledSpokenTextAttributes": "size:; family-name:; weight:400; indent:0; underline:none; strikethrough:false; justification:left; style:normal; paragraph-style:; text-spelling:none;", "chatMessageVerbosity": 0, "presentTimeFormat": "%X", "magBrightnessLevel": 0, "presentRequiredState": false, "enableMagCrossHairClip": false } }
OK, I found some more interesting things with the caps_lock toggling of case and speaking thereof. Perhaps I didn't realize this may be necessary. What I found is when the Caps_Lock key is assigned to be the Orca key, I have to press Orca+Backspace for bypassing Orca and then press the Caps_Lock key by itself. then it works as I would normally expect. Is this by design or is the Caps_Lock supposed to work by itself without pressing bypass first? On another not mentioned in item #7 above, I too am seeing situations where some dialogs or applications will not speak. This can be surely demonstrated when going into gedit or the run dialog. When opened first, Orca says "Frame." But once I alt+tab away and back to this dislog or application, then Orca will say that it is a Text control and then key echoing and other navigation works properly. Not sure if this last observation should be opened as a separate bug or what.
(In reply to comment #10) > then it works as I would normally expect. Is this by design or is the > Caps_Lock supposed to work by itself without pressing bypass first? It's by design because in laptop layout the CapsLock key is no longer serving as the CapsLock key, but as the Orac modifier. > On another not mentioned in item #7 above, I too am seeing situations where > some dialogs or applications will not speak. This can be surely demonstrated > when going into gedit or the run dialog. When opened first, Orca says "Frame." > But once I alt+tab away and back to this dislog or application, then Orca will > say that it is a Text control and then key echoing and other navigation works > properly. Not sure if this last observation should be opened as a separate bug > or what. Oh good point, I'll keep that in mind when testing which I am about to. As for the separate bug, I filed bug 663992 a few weeks ago against AT-SPI. Seems to be a weird timing issue where most of the time, but not always, the widget in question claims to not be focused. We get a lot of events for things you are not in, and you would not want us to present them, so we need to rely upon focused widgets telling us they are focused. Having said that, if we get much closer to 3.4 without a fix, I might attempt to hack around it. :-/
When composing a message using TB, the chars typed are not announced by orca. Orca acts as if the key echo option is not checked.
When typing in gedit, gnome-terminal and etc, some punctuations are not announced by orca, although 'alpha numeric and punctuation' option is set. This happens only when the verbosity is not set to all. If verbosity is set to all, all punctuation typed is announced.
I am not sure if this is the correct place to report. I can not assign a key bind to an orca function that does not have a key bind assigned. If the function has no key assigned, I can not add a key. If the function has a key assigned, I can reassign a new key.
Dave, your comment #7 bug should be fixed in master. José your comment 12 should be as well I think. Please test. Thanks!
(In reply to comment #13) > When typing in gedit, gnome-terminal and etc, some punctuations are not > announced by orca, although 'alpha numeric and punctuation' option is set. This > happens only when the verbosity is not set to all. > If verbosity is set to all, all punctuation typed is announced. Could you please test this in master? I think that it is the same issue as comment 12. I get my punctuation echoed.
(In reply to comment #14) > I am not sure if this is the correct place to report. > > I can not assign a key bind to an orca function that does not have a key bind > assigned. > If the function has no key assigned, I can not add a key. If the function has a > key assigned, I can reassign a new key. I can bind keys even if they have no keybinding. Could you please capture a full debug.out. Maybe there's a traceback. Thanks!
(In reply to comment #15) > Dave, your comment #7 bug should be fixed in master. José your comment 12 > should be as well I think. Please test. Thanks! When typing in the body of the message, the chars are now echoed, but when typing in the subject or in the to field, the chars are not echoed.
(In reply to comment #16) > (In reply to comment #13) > > When typing in gedit, gnome-terminal and etc, some punctuations are not > > announced by orca, although 'alpha numeric and punctuation' option is set. This > > happens only when the verbosity is not set to all. > > If verbosity is set to all, all punctuation typed is announced. > > Could you please test this in master? I think that it is the same issue as > comment 12. I get my punctuation echoed. Unless I am doing something wrong, the problem persists. I can not hear some chars when typed. Some char that I don't hear: . , ; |
Created attachment 204814 [details] debug file when I tried to assign a key to a function
Regarding my issue #7: I now get double key echo when typing into terminal windows. Other text entry areas I've tested, so far, seem to echo as I desire.
(In reply to comment #18) > (In reply to comment #15) > > Dave, your comment #7 bug should be fixed in master. José your comment 12 > > should be as well I think. Please test. Thanks! > > When typing in the body of the message, the chars are now echoed, but when > typing in the subject or in the to field, the chars are not echoed. Was this something that broke as a result of the recent refactor? If you go back to Orca 3.3.3 are they echoed there as well?
Created attachment 204817 [details] [review] test patch for gnome-terminal (In reply to comment #21) > Regarding my issue #7: I now get double key echo when typing into terminal > windows. Other text entry areas I've tested, so far, seem to echo as I desire. Dave, could you please apply this patch to gnome-terminal and tell me what breaks for you? In a nutshell, we do a bunch of crazy hacking in the onTextInserted() method for gnome-terminal. Much of it -- perhaps none of it -- might no longer be needed as a result of the refactor. All my patch does is bypass the crazy hacking and allow the default script to handle the event. Note that this patch is not committed anywhere. Thanks in advance!
(In reply to comment #22) > > > When typing in the body of the message, the chars are now echoed, but when > > typing in the subject or in the to field, the chars are not echoed. > > Was this something that broke as a result of the recent refactor? If you go > back to Orca 3.3.3 are they echoed there as well? The problem is not present in version 3.2.1, the version present on Ubuntu 11.10.
(In reply to comment #24) > (In reply to comment #22) > > > > > When typing in the body of the message, the chars are now echoed, but when > > > typing in the subject or in the to field, the chars are not echoed. > > > > Was this something that broke as a result of the recent refactor? If you go > > back to Orca 3.3.3 are they echoed there as well? > > The problem is not present in version 3.2.1, the version present on Ubuntu > 11.10. Hmmm.... That doesn't tell me if the regression is from this refactor. But in a way that might not matter. I just tried it with master in Thunderbird and I get keyecho in both the body and the subject.You also had those espeechfactory tracebacks. I reversed the change provided which caused you to get those tracebacks. But what concerns me is why you even landed in that module to begin with. The only two people at least so far who seem to find themselves there are people who upgraded from earlier installs. And, as I stated in response to another message on the Orca list, I cannot help but wonder if you have cruft around from an earlier version. Therefore, if you could temporarily move your settings files ($HOME/.orca if one exists, along with $HOME/.local/share/orca). Also physically delete your master install (not just uninstall it; delete it). Then rebuild and reinstall it. And if all of that is done, and you still have a problem, please attach a tarball with your settings because maybe you have something special in your settings which I lack which is responsible for you seeing the problem and me not seeing it. Lastly, you are using pygobject 3.0.2 right? Without 3.0.2 certain aspects of binding keybindings is broken. That is why that version is a dependency of Orca master.
I just fired up Thunderbird 9 here on my system with an Orca master from morning of 01/08/2012 and I can type in the message body but keys are not echoed in the subject field. Keys do echo in message body. As I type this bug text, I am not getting any key echo at all.
(In reply to comment #25) > > > Was this something that broke as a result of the recent refactor? If you go > > > back to Orca 3.3.3 are they echoed there as well? > > > > The problem is not present in version 3.2.1, the version present on Ubuntu > > 11.10. > > Hmmm.... That doesn't tell me if the regression is from this refactor. But in a > way that might not matter. I just tried it with master in Thunderbird and I get > keyecho in both the body and the subject.You also had those espeechfactory > tracebacks. I reversed the change provided which caused you to get those > tracebacks. > > But what concerns me is why you even landed in that module to begin with. The > only two people at least so far who seem to find themselves there are people > who upgraded from earlier installs. And, as I stated in response to another > message on the Orca list, I cannot help but wonder if you have cruft around > from an earlier version. Therefore, if you could temporarily move your settings > files ($HOME/.orca if one exists, along with $HOME/.local/share/orca). Also > physically delete your master install (not just uninstall it; delete it). Then > rebuild and reinstall it. And if all of that is done, and you still have a > problem, please attach a tarball with your settings because maybe you have > something special in your settings which I lack which is responsible for you > seeing the problem and me not seeing it. > I didn't update my system, It was installed from fresh. After installed I applied all updates and built orca from master. > Lastly, you are using pygobject 3.0.2 right? Without 3.0.2 certain aspects of > binding keybindings is broken. That is why that version is a dependency of Orca > master. I am using pygobject 3.0.3 grabbed from deb http://ppa.launchpad.net/gnome3-team/gnome3/ubuntu oneiric main repository. I suspect that the problem is caused because I have orca 3.2.1 installed and it is the version that is started when my machine boots. After boot the machine, I kill orca and start the new version that is installed in another directory, directory not present in the current path. I removed and recreated orca config files and all worked fine, until I reboot my machine. After recompile orca, install it in the /usr/local directory, remove and recreate the config files and reboot my machine, I got best results. Now I can type message in TB and the keys are echoed. I can also assign a key to orca function. What happens is that master is started when my machine boots. A problem that I found is that keys are echoed two times in gnome-terminal.
(In reply to comment #27) > Now I can type message in TB and the keys are echoed. I can also assign a key > to orca function. Woo hoo! And thanks for the follow-up. > A problem that I found is that keys are echoed two times in gnome-terminal. Yeah, Dave found that as well. See my comment #23 and the test patch. It should solve the double echo. My concern is determining for sure that it's safe to rip out all the onTextInserted() hacks from the gnome-terminal script.
(In reply to comment #23) > Created an attachment (id=204817) [details] [review] > test patch for gnome-terminal Ok, the keys are not echoed two times but seems that the patch has a side effect. The response of commands typed in terminal are not spoken by orca. If I type in terminal a pwd command, the result of the command is not read by orca. I need to use a flat revew command to read the result.
Created attachment 204939 [details] [review] proposed patch for gnome-terminal (In reply to comment #29) > (In reply to comment #23) > > Created an attachment (id=204817) [details] [review] [details] [review] > > test patch for gnome-terminal > > Ok, the keys are not echoed two times but seems that the patch has a side > effect. The response of commands typed in terminal are not spoken by orca. > If I type in terminal a pwd command, the result of the command is not read by > orca. > I need to use a flat revew command to read the result. If that really is the only side effect you noticed, then my theory that much of that code can be removed seems to be reasonable. Thus this patch is a real proposed solution. Please test and let me know. Thanks!
(In reply to comment #30) ... > > If I type in terminal a pwd command, the result of the command is not read by > > orca. > > I need to use a flat revew command to read the result. > > If that really is the only side effect you noticed, then my theory that much of > that code can be removed seems to be reasonable. Thus this patch is a real > proposed solution. Please test and let me know. Thanks! Ok, now orca announces the responses generated by a command. If I type pwd, orca reads correctly the response. I found another problem however. Orca does not anounce the result when I type part of a command and then I press the tab key. If I press cd /home/vil and tab key, orca does not announce the completion. Thanks.
(In reply to comment #31) > (In reply to comment #30) > ... > > > If I type in terminal a pwd command, the result of the command is not read by > > > orca. > > > I need to use a flat revew command to read the result. > > > > If that really is the only side effect you noticed, then my theory that much of > > that code can be removed seems to be reasonable. Thus this patch is a real > > proposed solution. Please test and let me know. Thanks! > > Ok, now orca announces the responses generated by a command. > If I type pwd, orca reads correctly the response. > > I found another problem however. > Orca does not anounce the result when I type part of a command and then I > press the tab key. > If I press cd /home/vil and tab key, orca does not announce the completion. > Thanks. Another problem is that orca announce chars typed when typing a password in the terminal. If I do for example a sudo apt-get update and the password is required, orca reads each char typed in response to the password.
Perhaps I am doing something wrong, but orca does not announce the status of caps lock key when changed. I press CapsLock+backspace and then press CapsLock key again. I know that the status was changed but orca does announce the new status.
Comment on attachment 204939 [details] [review] proposed patch for gnome-terminal I committed this with a slight tweak to also echo Tab completion. (I still need to address the password echo, but that's a different issue.)
(In reply to comment #34) > (From update of attachment 204939 [details] [review]) > I committed this with a slight tweak to also echo Tab completion. (I still need > to address the password echo, but that's a different issue.) Works as expected. Thanks.
I am not sure if this is related to the refactory, but now I can not scroll in FF using arrows. It seems that when I use arrows to navigate, orca jumps to the begin of the document. I tried with firefox 10 and fire fox 9.0.1 with the same results.
Just committed a hack to master which should work around the problem of echoing keypresses for terminal password prompts. The real thing to do is make it possible for ATs to know when the user is being prompted for a password as having to guess leads to all sorts of problems. :-/ Piñeiro opened bug 668025 for this issue. http://git.gnome.org/browse/orca/commit/?id=1daef1254b74c0cc0a3226e13c61d1553212f6c7
(In reply to comment #36) > I am not sure if this is related to the refactory, but now I can not scroll in > FF using arrows. > It seems that when I use arrows to navigate, orca jumps to the begin of the > document. > I tried with firefox 10 and fire fox 9.0.1 with the same results. I just tried it using Orca from master and firefox 9.0.1 in Fedora rawhide. It is working for me. So a couple of ways you can help me get to the bottom of your issue: 1. Did you press F7 to enable caret navigation in Firefox? (This isn't *always* necessary, but when strange things happen this sometimes seems to help.) 2. If you build and install Orca v3.3.3 does the problem magically go away? (Having data from Orca v3.2.x is not of use when trying to determine if this is a keyboard related regression). 3. Anything interesting in a full debug.out? 4. Does it happen on all pages or just some pages?
(In reply to comment #38) > (In reply to comment #36) > > I am not sure if this is related to the refactory, but now I can not scroll in > > FF using arrows. > > It seems that when I use arrows to navigate, orca jumps to the begin of the > > document. > > I tried with firefox 10 and fire fox 9.0.1 with the same results. > OOPS! Seems that I found my problem. I forgot to uncheck the 'grab focus on object when navigating' option in orca preferences. forgive my mistake.
I found another problem related to terminal. It seems that orca announces the chars typed only if they are placed in the end of the text. If they are inserted in the begin or in the middle of the text, they are not announced. To reproduce you can try the following: 1. In the terminal type the following text: d e f 2. Move the cursor to the begin and type the following: a b c Orca will read the 'd e f' but will not read the 'a b c'.
When reading a message in thunderbird, ctrl+home and ctrl+end jumps to the begin of the message.
When reading a message in thunderbird if I activate the learn mode and press the escape key, the message is closed together with the learn mode.
In terminal try the following steps: 1. type ls -l /usr/bin/ |more Orca reads the content of screen without problems. 2. Press space bar to advance to the next page. Orca does not read the content of the second page.
(In reply to comment #42) > When reading a message in thunderbird if I activate the learn mode and press > the escape key, the message is closed together with the learn mode. This along with the Tab key pass through should be fixed in master.
(In reply to comment #43) > In terminal try the following steps: > 1. type ls -l /usr/bin/ |more > Orca reads the content of screen without problems. > 2. Press space bar to advance to the next page. > Orca does not read the content of the second page. Fixed in master.
(In reply to comment #41) > When reading a message in thunderbird, ctrl+home and ctrl+end jumps to the > begin of the message. Confirmed -- and confirmed for Orca 3.3.3 i.e. Orca prior to the refactor described in this bug. That makes it some other issue. I would like this bug to focus on refactor regressions. Therefore, I have opened up bug Bug 668884 for the Ctrl+End issue issue.
> Since I use orca in a laptop, I configured orca to use capslock as the > orca key. > In learn mode if I press for example capslock+d, the D character is > inserted in the text that I was previously editing. > > To reproduce: > 1. Launch gedit. 2. Make sure that orca is configured to use capslock as the orca key. 3. Press capslock+h to activate the learn mode. 4. Press capslock+d assuming that combination has no function associated. 5. Press the escape key. Note that a character D (in uppercase) is present in the text.
I confirm the above issue also happens on a desktop layout when kp_insert is the Orca modifyer.
Also, on a desktop machine, if you press a locking key while in learn mode, the state of that locking key is toggled when it should not be.
Also in learn mode, on my desktop machine If I press kp_begin, Orca tells me that I've pressed that key. But if I press kp_insert + kp_begin, Orca says "speaks the current flat review object". This is incorrect, kp_begin on its own is the flat review command. The same goes for all kp_ keys
(In reply to comment #47) > > Since I use orca in a laptop, I configured orca to use capslock as the > > orca key. > > In learn mode if I press for example capslock+d, the D character is > > inserted in the text that I was previously editing. > > > > To reproduce: > > 1. Launch gedit. > 2. Make sure that orca is configured to use capslock as the orca key. > 3. Press capslock+h to activate the learn mode. > 4. Press capslock+d assuming that combination has no function associated. > 5. Press the escape key. > > Note that a character D (in uppercase) is present in the text. Should now be fixed in master. While I was at it, I also addressed your request to first echo the keypress before speaking the function when in learn mode. Not a regression, but easy enough to do. <smiles> Please test. Thanks!
(In reply to comment #48) > I confirm the above issue also happens on a desktop layout when kp_insert is > the Orca modifyer. Should be fixed in master. Please test. Thanks!
(In reply to comment #50) > Also in learn mode, on my desktop machine > > If I press kp_begin, Orca tells me that I've pressed that key. But if I press > kp_insert + kp_begin, Orca says "speaks the current flat review object". This > is incorrect, kp_begin on its own is the flat review command. The same goes > for all kp_ keys Actually, Orca has a *bunch* of flat review commands -- perhaps more than needed. But in the case of kp_begin without the Orca modifier held down, it does a flat review of the current word; not the current object. Furthermore, what Orca is doing (and has always done, even before this refactor) when you are in Learn Mode is it looks for a "match". A "match" is the thing it will do if you were not in Learn Mode. The only difference is in Learn Mode it says what it would have done; outside of Learn Mode it actually does it. Long way of saying, I think what you describe here is not actually a bug at all; and if it is, I do not think it's a refactor regression. (In which case it belongs in a new bug.) Hope this makes sense. And I really appreciate your testing this thoroughly!!
(In reply to comment #51) > > Should now be fixed in master. While I was at it, I also addressed your request > to first echo the keypress before speaking the function when in learn mode. Not > a regression, but easy enough to do. <smiles> Please test. Thanks! Works fine, thanks.
(In reply to comment #49) > Also, on a desktop machine, if you press a locking key while in learn mode, the > state of that locking key is toggled when it should not be. I just tested in Orca v3.3.3 (i.e pre-refactor Orca). This issue is present there too, which doesn't really surprise me. Consuming the Caps Lock key has always been a pain at best. Anyhoo, because this is not a refactor regression, I've opened bug 669213 for your report. Thanks!!
(In reply to comment #33) > Perhaps I am doing something wrong, but orca does not announce the status of > caps lock key when changed. > I press CapsLock+backspace and then press CapsLock key again. I know that the > status was changed but orca does announce the new status. Some position about this comment? > I press CapsLock+backspace and then press CapsLock key again. I know that the > status was changed but orca does not announce the new status. Am I doing something wrong? Thanks.
(In reply to comment #56) > (In reply to comment #33) > > Perhaps I am doing something wrong, but orca does not announce the status of > > caps lock key when changed. > > I press CapsLock+backspace and then press CapsLock key again. I know that the > > status was changed but orca does announce the new status. > > Some position about this comment? Yes: I'm working as fast as I can. <smiles>
Joanie, Okay so kp_begin is "speaks the current flat review item or word", and kp_insert + kp_begin is "speaks the current flat review object". I was confusing these. I confirm that these keystrokes are doing what they are supposed to while not in learn mode. What was happening however was that in learn mode, Orca was not announcing the function of a flat review command when it was a single keystroke, such as kp_begin on its own. However something you've changed means it now is so consider it sorted! Thanks.
(In reply to comment #40) > I found another problem related to terminal. > It seems that orca announces the chars typed only if they are placed in the end > of the text. > If they are inserted in the begin or in the middle of the text, they are not > announced. > > To reproduce you can try the following: > 1. In the terminal type the following text: > d e f > > 2. Move the cursor to the begin and type the following: > a b c > Orca will read the 'd e f' but will not read the 'a b c'. I think I've got this one fixed in master. Please test. Thanks!
Ok, the speaking of Caps Lock state changes when in Bypass Mode should be fixed in master.
Alrighty boys and girls, I have read through the previous 60 comments. I am operating under the following assumptions with respect to reported issues: 1. I fixed it, or 2. I opened a new bug for it because it wasn't a refactor regression, or 3. You figured out the issue was on your end But I'm also rather sleepy now. <grins> So.... What issues remain that I'm not noticing? Thanks again for all your testing and patience with this refactor!
(In reply to comment #60) > Ok, the speaking of Caps Lock state changes when in Bypass Mode should be fixed > in master. Hi Joanie. Not working when in terminal. Works fine in other apps.
Now in learn mode, orca announces the key name and the function associated to the key. This does not happen if I am in terminal. Seems to work fine in other apps.
currently the state of locking keys is not being announced in gnome-terminal. This is on my desktop machine where the Orca key is kp_insert. Not in learn mode or bypass mode or anything, just switch to gnome-terminal and press a locking key and you wont hear the state being reported. The state of locking keys is reported in other applications.
Learn mode and locking key state are now working for me in gnome-terminal. Please test. Thanks!
(In reply to comment #65) > Learn mode and locking key state are now working for me in gnome-terminal. > Please test. Thanks! Works for me very well. Great job and thanks.
Since it seems like I got all the (known so far) regressions, and given this bug has a bunch of comments, I'm going to close this one out as FIXED. Should new issues show up, we can open a new bug (one per issue) as we normally do. Thanks to all who tested and provided feedback!!