GNOME Bugzilla – Bug 373387
Users should be able to lock/unlock the "Lock" modifier even if Caps Lock is the Orca modifier
Last modified: 2010-09-20 10:55:35 UTC
With the fix for http://bugzilla.gnome.org/show_bug.cgi?id=373381, Orca now allows the Caps_Lock key to be used as the Orca modifier. When this is done, however, the user loses the ability to lock/unlock the "Lock" modifier. Some users, such as data entry users, need the lock/unlock ability to be productive in their jobs. Possibilities to re-enable the lock/unlock modifier include Shift+Caps_Lock, a double tap on the Caps_Lock key, etc.
I would prefer the double tap of the caps-lock key. This is how JAWS does it and it is what a lot of people will be used to.
Doesn't the bypass key solve this one?
(In reply to comment #2) > Doesn't the bypass key solve this one? If Caps_Lock is the Orca modifier, Orca currently clears the locking ability of the Caps_Lock key. So...the bypass key doesn't solve this one. :-(
The idea of using a double tap of the modifier key sounds like an interesting way to do it. I personally haven't seen it done that way before as I am not a Jaws user. Please don't add a feature just because Jaws does something that way. Another viable way to address at least the caps lock issue would be to use a shift combination to pass the real meaning through. An example of this method is done in Speakup for the Linux console. But this particular situation may not apply well to something like the insert key so the double strike method may be more universal.
(In reply to comment #4) > The idea of using a double tap of the modifier key sounds like an interesting > way to do it. I personally haven't seen it done that way before as I am not a > Jaws user. Please don't add a feature just because Jaws does something that > way. I tend to agree. As the lead for Orca, I permit features to get in because they address specific user needs. That is, I prefer to ask "why" questions about the user experience first rather than just doing monkey see, monkey do. Sometimes, this results in features similar to other screen readers, but sometimes it results in more compelling access. > Another viable way to address at least the caps lock issue would be to > use a shift combination to pass the real meaning through. An example of this > method is done in Speakup for the Linux console. But this particular situation > may not apply well to something like the insert key so the double strike method > may be more universal. An issue with using a modifier key to allow the passthrough is that the Orca key is often used with modifiers and other keys. For example, Orca+Shift+xxx (where 'xxx' is some key) is used for handling a lot the 'previous' operations associated things like bookmark navigation, structural navigation, etc. So, if we had Shift+Orca as a means to pass the 'real' key through, it could conflict with the Orca+Shift+xxx operations. We could potentially handle this by doing the passthrough on key releases, though. That is, we would detect when Shift+Orca had been pressed and then only do the passthrough when both keys had been released and no other intervening key had been pressed. The passthrough would be an atomic press/release operation. With the double tap method, the first press/release would basically set a flag and the second press would cause a press of the 'real' key to be emitted and the subsequent release would cause a release of the 'real' key to be emitted.
Willie, this problem presists in Karmic (2.27.3-0ubuntu1) is there way to resolve this before this next stable release.
(In reply to comment #6) > Willie, this problem presists in Karmic (2.27.3-0ubuntu1) is there way to > resolve this before this next stable release. It's near the bottom of my priority list and is thus marked as FUTURE in the Target Milestone. If you want to provide a patch that works, though, I'll happily review it.
Created attachment 140117 [details] [review] allow pass through to accept caps_lock Hi Will, With patch from 591034, this patch allows the pass through key to allow the locking ability of caps_lock. We get a small delay when we enable caps_lock, because xmodmap does not like keys to be pressed when other keys are being processed.
Jon, this is very cool. Thanks for doing this!! I did notice something, however: When using the desktop layout and with the echoing of locking keys enabled, Orca speaks confirmation that Caps_Lock has been toggled as expected. When I switch to laptop layout and press Orca+Backspace followed by Caps_Lock, Orca does not speak any confirmation.
With the more generic patch for bug #591304, the patch for this has become obsolete and needs more work. :-( I'm marking this for 2.27.91, but only if we can do it and it doesn't involve a lot of risk in the code.
Created attachment 140299 [details] [review] rev 2 Hi Team, I had to go out before submitting the patch, but had the time to mark my patches as obsolete, sorry that you looked at expired code. Will, I took the liberty to nab your comments from patch.591034-4, since they were better than mine. I also kept things in orca_state.py, since I think I will need them for (bug 536827 - Provide configuration GUI option to set the Orca key/modifier) This patch includes the fix for 591034, and speaks/brailles caps lock on/off. Thanks
Created attachment 140680 [details] [review] rev 3 thanks to git add -p, patch much smaller. Depends on patch revision 5, from 591034. Please test. Thanks
I wrestled with this one. The impact of this bug seems to be mostly on public information systems where the system could be left in a state where the CapsLock modifier is left unbound. In most other cases, it's likely to be a single user machine and the single user would be an Orca user running Orca full time. So, the bug of not resetting the CapsLock modifier in some cases is indeed a bug, but not one that is huge (which is why this is marked as minor). The code changes are kind of big for this, so I put this bug in more of the "high risk"/"low impact" category, which is stuff we want to do early in the release cycle versus the end. I'm going to push this one out for FUTURE and we'll take a poke at it early in the 2.29.x cycle.
Review of attachment 140680 [details] [review]: This might be something to consider for 2.29, but we'll need to test it thoroughly.
Created attachment 162205 [details] [review] Possible fix for bgo#373387 - Users should be able to lock/unlock the Lock modifier even if Caps Lock is the Orca modifier.
Hi Joanie, The above patch is against master, and pylinted to 10. Unfortunately we still get a small delay when we enable bypass mode, then press caps lock, before we can start typing, but not sure what i can do to get rid of that. Do things look reasonable otherwise? Thanks
Hey Jon. Thanks for doing this! It'll definitely be great to have. I just gave it a spin and noticed the following: * The delay is 2 seconds long on my main system. That's pretty noticeable. * The delay seems to be the amount of time it takes for the call to os.system() in _xmodmapMods() to return. * After entering bypass mode and pressing Caps Lock, I see the indicator on my keyboard change immediately and Orca speaks that change correctly and immediately. So far so good (not counting the delay). However: * If I press Caps Lock again before that call to os.system() returns, I can keep toggling the Caps Lock, but Orca says nothing -- or sometimes it says the wrong state. So once I can start typing again, the characters are not what I'd expect were I not able to see the keyboard indicator. Between the significant delay and the potential for confusion, I think we need to figure out why it's taking so long for the call to os.system() to return. Make sense?
*** Bug 623125 has been marked as a duplicate of this bug. ***
Hy Jon, I tryed apply your last patch with Orca git master version and try test. The delay problem is I see same, but I see another interesting think with I don't no this is valid or not: Why spokening Orca after I apply your patch the "Enter", "Left Start Button", "Tab" etc keys? In key echo page my system only the Enable alphanumeric and punctuation keys, enable locking keys check boxes are checked. Your openion your patch possible finalized before 2.30.3 maintenance version, or only fit with 2.32 version remaining developing cicle?
[OT] While working with Ubuntu Lucid I found that problem some users faced was due to Lock keymap being unset. Wonder what causes this issue on some machines. http://playingwithsid.blogspot.com/2010/06/orca-caps-lock-issue.html
Arki, thank you the manual. I tryed your suggestion. Caps lock on/off working if I add, but for example if I use an Orca command (for example the flat review command), the capslock state is changed. What the default in Lucid now if accessible install happened? Capslock added or not?
Attila, Only few Lucid machines exhibit this problem so its difficult reproduce this problem.
Jon, I'm trying to plan for between now and 3.0. Is this one going to happen do you think or not? (Just in case/btw point: I'm adding '3.0?' to the whiteboard so that I can search for these items later. Regardless of what you personally plan to do w.r.t. this bug, please do not clear the whiteboard field. Thanks!)
I can do this without the crazy delay. Still working on the final solution, however.
Created attachment 165713 [details] [review] Fix http://git.gnome.org/browse/orca/commit/?id=ed712f3f838ecf02d40e0799dea24dba6324312e