GNOME Bugzilla – Bug 95656
Keyboard Accesibility Configuration lacks way to set the XFree86 Sticky Keys Latch to Lock property
Last modified: 2011-09-09 14:17:03 UTC
Package: control-center Severity: normal Version: 2.0.1 Synopsis: Keyboard Accesibility Configuration lacks way to set the XFree86 Sticky Keys Latch to Lock property Bugzilla-Product: control-center Bugzilla-Component: Keyboard Accessibility Description: Description of Problem: The existing configuration dialog in the configuration of StickyKeys properties using the GNOME Control Center lacks a way to set the StickyKeys LatchtoLock property. Thus the modifier bits of the StickyKeys stay on until a non-modifier key is pressed. This option should be tunable so that two consecutive presses of a key turns the stick bit off. This is different from the two key disable property for sticky keys. The current implementation overrides the settings of StickyKeys present in the environment with it's values. Instead it should read the status and only affect those settings that have been set in the options provided by the GNOME Control Center. Steps to reproduce the problem: 1. Enable Sticky keys. 2. Press any key with a modifier bit e.g Alt or Control or Shift 3. Press the same key again. Actual Results: The Sticky bit is not cleared. Expected Results: Sticky bit should be cleared. How often does this happen? Everytime Additional Information: The tool accessx available for Linux provides the following options with respect to StickyKeys: [+/-] stickykeys - Turn StickyKeys on/off [+/-] stickylatchtolock - Lock the sticky bit until a non-modifier key is pressed [+/-] stickytwokeydisable - Disable sticky keys if two keys with modifier bits are pressed simultaneously The second option is missing from GNOME Control Center and it defaults to on which is undesirable. ------- Bug moved to this database by unknown@bugzilla.gnome.org 2002-10-12 23:49 ------- The original reporter (kitty@cse.wustl.edu) of this bug does not have an account here. Reassigning to the exporter, unknown@bugzilla.gnome.org. Reassigning to the default owner of the component, control-center-maint@bugzilla.gnome.org.
Bill : Do we need support for this too ?
Bill?
Not sure, but this sounds like a useful feature. I am seeking opinion on how critical this feature is.
I don't know what are the requirements for a bug to be marked critical. But without this feature, it is a real pain to use GNU Emacs. I use the sticky keys to help reduce pain in my wrists. The problem with the sticky keys feature in GNOME is that if I hit a modifier key by mistake, I can't enter any other key (without screwing up) before I hit a non-modifier key. It will be a very useful feature to hit the same modifier key and have the stickiness turned off. XEmacs provides this by default. But I have to resort to using XFree86 accessibility features if I want to use GNU Emacs. Presently I am working around by using a program called ax in addition to using GNOME, which is a PITA. On the same topic, where can I find documentation about the shortcuts which turn on each of the accessibility features in GNOME. I happen to hit some key combination by mistake and it turns on Bounce Keys. I thought GNOME froze and I killed it twice before figuring out the problem. It would be great if the GNOME accessibilty features show a small keyboard icon in the panel when turned on.
HI Kitty: I think you may be talking about some bug other than this one; currently, it is possible to 'delatch' modifiers by pressing them three times. The default behavior is this, for instance with the Shift modifier: press once: shift latches press again: shift locks press a third time: shift unlocks and unlatches. So in your case, if you hit Shift by accident, pressing it two more times should un-latch. At least, it does on my system and others which I have tried. _This_ bug is about whether we should allow the user to switch between the current behavior (which allows locking of modifiers by pressing twice) and "non-locking" behavior which would just toggle between "latched" and "unlatched" when a modifier is pressed multiple times in succession. As for your suggestion about a panel 'icon' (panel applet, probably) that shows the current state of BounceKeys, StickyKeys, etc, please see bug 98488.
Updating status_whiteboard field to reflect A11Y team's assessment of accessibility impact.
Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME bug list :)
Calum why is this major ? Adding this is simple, the open question is still whether its useful enough to balance the added complexity. I'd vote that its not, but then again I don't use this. Can the a11y team provide some explicit feedback on this ?
the wustl address (wustl info submitter above) is from TRACE center, which developed AccessX and was a major contributor to XKB's design. If they say this is needed, I'd tend to accept that as expert advice. We are seeking some feedback on this now, but kitty's argument is fairly compelling (i.e. if someone has turned latch-to-lock off, we shouldn't be turning it back on automagically); this also suggests that we should expose this property if it is indeed useful.
by the way Krishnakumar, pressing the modifier three times (instead of just two) will un-set it when latch-to-lock is on (which it is by default).
CC-ing Earl: what do you think? Do we need to support non-lock mode as well as the default? Note in case you've forgotten, turning _off_ latch-to-lock means that there's no way to lock a modifier. That will cause problems for metacity window navigation, since the only way to cycle through windows is via _holding down_ a modifier key (physically or via AccessX's modifier locking).
Just to clear up some facts. I am not associated with the TRACE center. WUSTL is Washington University, St.Louis. The TRACE center is at Wis-Mad (trace.wisc.edu). It would be good to have an option atleast, though I can type with both hands...
sorry kitty - of course wustl != wisc we ought to get feedback from Trace Center I guess before making a final decision. I am tempted to say "let's not add this" if we can do without it, because of the known regression it'll induce with respect to Metacity's modifier-key behavior (since consecutive Alt-TAB presses, with ALT released in between, will not cycle through the window list).
I believe Kitty is asking for the equivalent of a "Press modifier key twice to lock" feature in accessx where the bit that would be set would be something like "[+/-] stickynolockontwopress". If my understanding of the issue is correct, I agree that this is a feature that needs to be supported in accessx XKB; it's a feature in accessx CDE and Windows' equivalent today. Earl Johnson
My last post wasn't clear, try #2. I believe Kitty is asking for the equivalent of a "Press modifier key twice to lock" feature in accessx. The way this feature works is: When set [checked], this setting would operate thusly: - lock a modifier key when it is pressed twice consecutively; - a third press on the modifier key unlocks the modifier key; - one press on the modifier key latches it till the next alpha-numeric key press. When not set [unchecked], this setting would operate thusly: - 2 consecutive presses on a modifier key leaves it unlatched - one press on the modifier key latches it till the next alpha-numeric key press. The bit being set would be something like "[+/-] stickynolockontwopress". If my understanding of the issue is correct, I agree that this is a feature that needs to be supported in accessx XKB. It's a feature in accessx CDE and Windows' equivalent today. Earl Johnson
Earl: we already have the latch-to-lock behavior if a modifier is pressed twice. Kitty seems to be asking for us to allow the user to turn that behavior on and off, i.e. asking for a checkbox in the accessibility capplet that allows latch-to-lock behavior to be suppressed. That's what I am not sure we want to expose. To restate; we currently support latch-to-lock by default, and have no means of suppressing latch-to-lock. That means that Shift-Shift will always lock Shift when StickyKeys is on, and pressing Shift a third time will unlock/delatch. The modifier state, if you press a modifier multiple times, looks like this: #1 (unset) -> latch->lock->unset-> ... Turning off the XKB latch-to-lock property would change this state sequence to: #2 (unset) ->latch->unset->latch->unset-> ... This seems to be what Kitty is asking for. XKB allows this, but it's not clear to me that this behavior is important to users. We _do_ know that the second behavior (latch-to-lock OFF) would cause problems with window navigation in GNOME, so if we do allow the user to switch between behaviors #1 and #2, we will have to deal with the difficult problem of fixing the resulting metacity 'regression'. - Bill
Bill; My second posting was still unclear apparently. I agree with Kitty; the following needs to be added to the accessx-xkb configuration UI and underlying functionality at some point to ensure it is feature compatible with both the accessx-cde and windows versions of stickykeys. latch->unset->latch->unset-> ... Having said this, the above feature is one I don't use so I'm not the best person for arguing for what release it should be fixed by. Earl
My concern is still that fixing this will expose a very-difficult-to-fix stopper bug. How does Windows window-list keynav work with StickyKeys if latch-to-lock is turned off? The Metacity (Gnome window manager) maintainers claim that sequential presses of Alt-TAB (releasing Alt in between) does _not_ cycle through the window list under Windoze, but that it toggles between 'next-and-most-recently-focussed window'. Just seeking full understanding of what wintel StickyKeys users will expect...
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
Given that the main reason to use this feature was apparently for window navigation, and wouldn't be needed in GNOME 3 (which has a specific mode for window management which doesn't require using modifiers), I'll close this as WONTFIX. I would certainly hope that if it was mightily important we would have had some movement on this since 2003... Also the feature is available through the number of key presses, as mentioned in comment 16.