GNOME Bugzilla – Bug 131406
g-s-d defeats XkbStickyKeysMask client-set if XkbAccess XKeysMask==0
Last modified: 2013-01-28 14:45:50 UTC
When GOK started it sets the stickykeys on, which is a required feature for GOK. GOK sets the sticky key either through gconf or via XKB. The gconf code path works fine. But when GOK tries to set via XKB (XkbChangeEnabledControls) stickykeys feature is not turned on. This problem is a consequence of interaction between XKB and gnome-settings-daemon (i.e. g-s-d might be inappropriately turning off StickyKeys if the 'enable' checkbox in our Keyboard Accessibility capplet is unset). Refer bug 129078 and bug 131339. When g-s-d is not running, GOK is able to set the stickykeys on. Thanks.
The action is not inappropriate. That was very deliberate. It was explicitly requested and debated for quite a while before being adopted. Please use gconf.
Sorry Jody, but I must reopen this bug. Please see bug 129078 and bug 131339. I'll take a lot of the responsibility for the misunderstandings here - I think basically there was miscommunication early in the XKB/AccessX process (involving, among other things, "compatibility requirements" with a "port" from Sun's pre-xkb implementation of this feature). Result was my early misimpression that there was an Xkb control that turned 'all' AccessX features on and off (as contrasted with the 'accessx keyboard shortcuts' XKB control). Somehow I never managed to shake that notion, and I didn't review the capplet code carefully enough to catch this problem until recently. So - basically this behavior was specified due to a misunderstanding, and probably I and Earl never really understood some of the communication from you over "why do you want this checkbutton". Maybe the problem was in the transfer from the GUI prototype (glade) and the implementation - at any rate, if we disabuse ourselves of the notion that there is in XKB some master toggle for accessx, we can clear HCI's obvections to the ugly checkbutton in GNOME, and generally improve the capplet. The current implementation, which uses gconf keys to force ally features off if 'enabled'/ShortCuts isn't set, is just wrong. Worse - it actually blocks exposing desirable features, such as the ability to allow AccessX features without enabling the keyboard shortcuts, or allowing the user to turn off the audio notifications when AccessX features change (now that we also have visual feedback possible via the accessx status applet). Sorry for the confusion here. As I said, I am sure I was a part of promulgating the heresy.
Jody: to clarify - GOK usually uses gconf to do this, as you suggest. But not all clients that wish to change AccessX settings will do so; some will use XKB directly. If we interfere with that action, we can be accused of breaking accessibility with the g-s-d code (letter-of-the-law) since one thing you explicitly cannot do is "defeat/disable/interfere-with assistive technology". One real-world example of another XKB accessx client (which isn't gconf-aware) is the old CDE accessx dialog. (We're supposed to cohabit with it in theory). Because the CDE applet does (IIRC!) couple the shortcut keys with the functionality, we may be OK in this case (as we tried to be at the outset); I suppose this needs testing now that the bits are all in place. But there are no doubt other XKB clients out there that may try to set StickyKeys or SlowKeys. I think the fix is not too hard, and I am willing to write the necessary patch as penance :-) But I'll need to make sure you're OK with the idea of the changes, provided Calum agrees. He seems to think this will improve the overall HIG-iness of the capplet anyway, and rationalize its behavior somewhat.
Nearly 10 years after, I'm willing to say that cohabitation with CDE's old AccessX dialogue isn't such a problem anymore. Feel free to reopen if you know a way around this.