After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 131339 - "enable keyboard accessibility" checkbox misfeature
"enable keyboard accessibility" checkbox misfeature
Status: RESOLVED FIXED
Product: gnome-control-center
Classification: Core
Component: [obsolete] Keyboard Accessibility
2.5.x
Other All
: Normal normal
: ---
Assigned To: Control-Center Maintainers
Control-Center Maintainers
AP3
Depends on:
Blocks:
 
 
Reported: 2004-01-13 14:54 UTC by bill.haneman
Modified: 2008-01-16 16:06 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description bill.haneman 2004-01-13 14:54:23 UTC
On examining the gnome-settings-keyboard-accessibility.c implementation
code and the XKB API, it seems that the 'enable keyboard accessibility'
checkbutton is a misfeature.

Contrary to what was once apparently believed, there's no master control
for the AccessX features in XKB: if XKB is loaded, they are available.  The
current implementation doesn't really do what it advertises anyway - what
it does now is turn on and off AccessX feature-change-notification beeps,
and turn on and off the ability to invoke StickyKeys and SlowKeys from the
keyboard.  As such, it belongs not at the top of the capplet (where we
never really liked it anyway), but in the 'Features' frame of the 'Basic'
notebook tab.  It ought to be split into two features anyway, since they
are probably worth controlling individually: i.e.
"Allow Sticky Keys and Slow Keys to be turned on and off from the keyboard"
"Beep when Sticky Keys or Slow Keys are turned on or off."

I've conferred with Calum to let him know my findings.  As far as I can
tell, the current checkbutton is a legacy misfeature from porting this
capplet from the CDE "AccessX" dialog, which originally used Sun's own
"AccessX" extension rather than the "AccessX" features in XKB.

Personally I think this is worth fixing during the UI review period for
GNOME 2.6, but I leave that to Calum's judgement.  I'd be willing to submit
a patch for this, since I think the fix would be quite straightforward.
Comment 1 bill.haneman 2004-01-13 15:33:48 UTC
I believe that the current logic (AccessX features are disabled by
g-s-d if XkbAccessXKeysMask bit is unset)
may also be partly responsible for problems with bug #129078.
Comment 2 Andrew Sobala 2004-01-13 16:03:40 UTC
Setting version to 2.5.x, since 1.4 seems a little old :)
Comment 3 Calum Benson 2004-10-21 16:40:24 UTC
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs.
 Filter on "SUN A11Y SPAM" to ignore.
Comment 4 bill.haneman 2006-02-21 11:56:46 UTC
This misfeature is causing problems for at least one user who needs MouseKeys but who doesn't want SlowKeys to keep turning on.  Is there any objection to fixing this bug?
Comment 5 Rodrigo Moya 2006-02-21 12:25:45 UTC
No objection from me
Comment 6 rush4hire 2006-03-26 14:54:47 UTC
I have been searching for a solution to this bugged stickykeys thing.

I space out when I'm workin on a script, and hold shift key down, and this crap comes up abt stickykeys.  Then wether I hit "Ok", or "Cancel", or "Settings", it will bug my computer.

If I click on something, it will hold there so the next thing I click on will highlight everything as if I dragged from there.

And everything is bugged till I reboot.

It's the only thing I hate about this operating system I just paid $160 for.

I don't want ANYTHING to happen when I hold down shift key for 8 seconds. Nothing at all, but how do I fix that?
Comment 7 Calum Benson 2006-04-26 17:06:02 UTC
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
Comment 8 Denis Washington 2008-01-05 15:59:52 UTC
I have put all keyboard a11y features into the keyboard capplet in SVN trunk and have removed the master switch on the way, replacing it with "Allow to turn accessibility features on and off from the keyboard" and "Beep when accessibility features are turned on or off". Please test and comment.
Comment 9 Denis Washington 2008-01-05 17:39:43 UTC
(In reply to comment #8)
> I have put all keyboard a11y features into the keyboard capplet in SVN trunk
> and have removed the master switch on the way, replacing it with "Allow to turn
> accessibility features on and off from the keyboard" and "Beep when
> accessibility features are turned on or off". Please test and comment.
> 

Unfortunately, while there is no master switch anymore, "Allow to turn accessibility features on and off from the keyboard" still must be enabled to enable the beep notifications. This is because this option still toggles the /desktop/gnome/accessibility/keyboard/enable switch, which is keyboard control and beeping in one function. I'll send a message to the control-center mailing list to discuss a solution (maybe additional gconf keys?).
Comment 10 Denis Washington 2008-01-05 18:54:38 UTC
2008-01-05  Denis Washington  <denisw@svn.gnome.org>

    * gnome-settings-daemon/gnome-settings-accessibility-keyboard.c:
      Don't depend on /desktop/gnome/accessibility/keyboard/enable for
      setting the AccessXFeedback flag; instead, set it if one of the
      notification bits is enabled.
Comment 11 Li Yuan 2008-01-11 06:50:16 UTC
Hi Denis, 

Does AccessXFeedback mean "Beep when accessibility features are turned on or off" or "Beep when accessibility features are turned on or off from keyboard"? Seems it only beep when I turn on/off the accessibility features (like sticky keys) from keyboard. If so I guess it is OK to depend on AccessXKeys...
Comment 12 Denis Washington 2008-01-11 10:54:16 UTC
(In reply to comment #11)
> Hi Denis, 
> 
> Does AccessXFeedback mean "Beep when accessibility features are turned on or
> off" or "Beep when accessibility features are turned on or off from keyboard"?
> Seems it only beep when I turn on/off the accessibility features (like sticky
> keys) from keyboard. If so I guess it is OK to depend on AccessXKeys...

AccessXFeedback doesn't mean beep on anything - it is a master flag to say "turn on beep notifications". Which notifications are actually enabled is controlled by additional flags. This means that if we depended on AccessXKeys for AccessXFeedback, this would mean that none of the beep notifications would work if the AccessXKeys option was disabled, which would be pretty ackward.

Comment 13 Denis Washington 2008-01-16 16:06:10 UTC
This should be fixed with gnome-control-center and gnome-settings-daemon 2.21.5, closing the bug.