GNOME Bugzilla – Bug 96483
Default values for bounce keys and slow keys should be zero.
Last modified: 2009-11-20 13:03:05 UTC
After a long discussion on the accessibility alias, it was agreed that: I should point out that I managed to go full circle in my flurry of emails on the badness of not making Bounce/Slow an exclusive action (email included below). Basically, it says go ahead and use checkboxes but set the sliders for Bounce and Slow at zero on initial startup to ensure nothing the capplet does initially will lock out the Bounce user. Thus requirement is that Bounce and Slow keys should not be mutually exclusive but that they should have initial zero values.
This requires a change in a schema file in libgnome.
Created attachment 11750 [details] [review] Patch to set default values to 0 for bounce and slow keys
Applied
*** Bug 599117 has been marked as a duplicate of this bug. ***
From a user standpoint -- any user should be able to walk up to any machine, hold the shift key down for 8 seconds and SlowKeys will be enabled and working. With the exception of enabling AccessX in the server, no other special configuration should have to be done. The effect of the patch for this bug is that the default values of 0 render SlowKeys and BounceKeys inoperable when the user activates them using the XKB/AccessX key sequences on the GDM desktop. Looking at http://mail.gnome.org/archives/desktop-devel-list/2002-October/msg00060.html, I believe the main concern is that we need to prevent a BounceKeys user from locking themselves out if they accidentally activate SlowKeys. Seems like and odd edge case to me -- in one case (accidentally enabling SlowKeys), you can't have any tremors and in the other (not being able to disable SlowKeys) you must have them. In the event this actually does happen, there is a "timeout" feature that will reset the machine to a normal working state after a period of time. Another possibility is the theoretical BounceKeys+SlowKeys user. Having been one of the people who developed AccessX, and having worked closely with the TRACE Research Center (the people who helped create the notions of StickyKeys and BounceKeys) in its design, I believe the BounceKeys+SlowKeys user is an extreme edge case (I can't say I ever had the pleasure of meeting one in my ~20 years in the accessibility space). So, the patch for this bug seems to have chosen to completely break the system to support a very odd edge case and a hypothetical user. :-( We need to restore the default behavior where any user should be able to walk up to any machine, hold the shift key down for 8 seconds and SlowKeys will be enabled and working. I propose reverting this patch.
Created attachment 148076 [details] [review] Patch to revert the previous patch Here's patch to revert the previous patch. This is so bad, IMO, that I kindly request (please :-)) that it be considered for GNOME 2.28.x as well. Thanks!
Ok to commit, but I wonder how we've managed to live with this for all these years if it's really that bad :-)
(In reply to comment #7) > Ok to commit, but I wonder how we've managed to live with this for all these > years if it's really that bad :-) I'm guessing somehow the desktop settings kicked in fine for some strange reason, but that the default values of 0 seem to have taken effect on the new login screen. So, the badness really is on the new login screen which we haven't seen until now. Committed to master - http://git.gnome.org/cgit/libgnome/commit/?id=0cbc77b0cc40321a071712f0a2661fc6a1531640 I don't see a gnome-2-28 branch - can I assume master will be used for gnome-2-28 and gnome-2-30 releases? Thanks!
The reason this problem showed up is because of GDM. For the normal user sessions, the GUI which allows users to turn on these features sets the default timeouts to reasonable values. However, when turning on these features via GDM, these features do not work since GDM doesn't set the timeouts. It seems better to just set better system timeouts for default use, rather than hacking GDM to also set the timeouts.