GNOME Bugzilla – Bug 129078
gok doesn't warn if it can't set sticky keys to 'on'
Last modified: 2004-12-22 21:47:04 UTC
I am surprised we don't seem to have a bug for this original feature; GOK used to warn (or warns?) if XKB isn't enabled. But if XKB's accessx isn't available, it seems that GOK doesn't always really set sticky keys. It shows the dialog indicating that sticky keys is enabled, but it doesn't set them. This seems to happen if the gconf key enabling keyboard accessibility is not enabled.
Created attachment 22502 [details] [review] Proposed patch
Hi Muktha: Thanks for this patch. I see that this only works #if USE_GCONF is true. I wonder, should we have an Xkb-only codepath too, that sets StickyKeys directly via XKB? I think the patch is OK to apply. David, I find the #if (1) rather worrying, that doesn't look like good coding style ;-) I wonder where that fragment came from? (could have been me!) Perhaps we should fix that while it has our attention.
I've applied Muktha's patch - thanks Muktha! Bill, I didn't look into an xkb path solution. The naughty if (1) { seems to exist to satisfy an end curly bracket needed by another preprocessing code path. We could replace the if (1) { with just a {, I think... I'm not sure the bug exists in the xkb only path. Could you take a look at that? My X knowledge is meek.
Bill, I'm just adding the typical cc suspects. Please also see my previous comment.
Bill, I did a quick check and the xkb path does seem to exhibit the bug and so will need to be fixed.
AP0 status doesn't get picked up for gok since our bug script uses gok priorities for this. So I marked it High, to keep it on our radar.
Attaching a small patch for the xkb code path.
Created attachment 23303 [details] [review] Patch for this problem
Bala: Looking at the new patch, I am a little unsure of what's going on. We shouldn't have to set XkbAccessXKeysMask in order to turn StickyKeys on programatically. David, what do you mean by 'the XKB code path does exhibit the problem'? I am thinking that *either the problem isn't really present when USE_GCONF isn't defined, or *there's a bug in the XKB in question, which causes it to erroneously require AccessXKeysMask to be enabled in order to turn on StickyKeys programatically, or: *the 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).
Note that Bala's patch is not appropriate unless the second of the three possibilities I outline above is the case. We need to confirm exactly what's going on, first.
Could on of you try temporarily modifying the preprocessing to force the XKB path and see if the problem exhibits itself for you? I recall it happening when I tried and so I suspect perhaps it is Bill's second possibility that we need to look at - but I need confirmation.
Bill, David, When I set USE_GCONF to 0, I am able to reproduce the problem, i.e. I can also see the problem through the Xkb code path. I killed gnome-settings-daemon and started gok (with #define USE_GCONF 0) and I was not able to reproduce the problem.
Thanks Balamurali, Do you have any comment on the need for XkbAccessXKeysMask?
Thanks Bala: that points to possibility #3, i.e. interaction between XKB settings and gnome-settings-daemon. I suspect that we need to make sure that gnome-settings-daemon does not 'unset' StickyKeys if 'XkbAccessXKeysMask' is unset. I think this is related to gnome-settings-daemon bug 131339 which I filed today (while investigating this issue).
David, I was under the impression that XkbAccessXKeysMask is for enabling the master control for the AccessX features in XKB (i.e required to enable the check box "Enable keyboard accessibility features" in the gnome-accessiblity capplet). Now I understand it is not. Bill, Can this bug be closed (since bug 131339 is created) or shall this bug be moved to gnome-settings-daemon. Thanks.
Closing this bug since bug 131406 has been created for the remaining problem.
David, Bill, When will be the XKB code path used ? Will there be a runtime check in gok in the future to determine if gconf exists or not ? If yes, then g-s-d--gconf problem does not exist. What do you think ?