GNOME Bugzilla – Bug 129537
gok keyboards don't update when X/XKB keymap changes
Last modified: 2004-12-22 21:47:04 UTC
GOK "compose" keyboards which are generated from XKB don't currently react to changes in the keymap. XKB does emit such notifications (as does Xlib), but GOK only reads the XKB configuration once, when creating the 'compose' keyboard. In the i18n case, switching keymaps on the fly is not uncommon; in fact GNOME 2.6 will include the 'gswitchit' applet which does this. So GOK needs to monitor the relevant XKB events and refresh its compose key labels accordingly. Possibly the best interim solution for this (though perhaps not the most performant solution long-term) would be to tear down and re-create the GOK compose keyboard on detection of a keymap-switch event. (David, I probably ought to take this one, since I wrote the existing XKB support for GOK).
I'd like to see this fixed for GNOME 2.6. It can wait till after feature freeze, since the current behavior is just a (serious) bug.
bumping up priority.
Created attachment 23849 [details] [review] patch (work in progress) which detects keymap switches and recreates compose keyboard. Don't switch while displaying the compose kbd itself!
above patch has some issues. For one thing, many, many XKB events are generated by a single xkb-switching operation from the gkb applet; and gok is recreating its compose keyboard with every one. also, it seems that the patch is toxic if you switch XKB keymaps while the gok compose keyboard is onscreen. Not great. lastly, we don't seem to get proper notifications when switching to the 'target' default keyboard as initially specified in the X config file. That's probably not gok's fault, possibly a bug elsewhere. Need to get more info on the events received from gkb, etc.
better patch which works whenever gkb switches keyboards; it uses GdkKeymap notification instead of XKB events directly. Still, for some keyboards we get too many keys-changed events; notably GNOME Default and US-105. For these keyboards there's a significant performance issue since we end up re-reading the XKB data many times when the switch occurs. However, the patch is nearing the point where it can reasonably be committed. Seems not to SEGV now.
Created attachment 23852 [details] [review] better patch, used GdkKeymap instead of XKB for its change notifications.
OK, I have a version of this patch which I'm happy about; it detects changes to GdkKeymaps. However, the newer versions of the gnome keyboard switcher don't change GdkKeymaps anymore :-/ they work by assigning groups and switching keyboard groups on-the-fly. This will require a bit more work to GOK's logic in order to support, so I am filing a separate bug for that work.
new related bug is bug 132853.
Created attachment 23875 [details] [review] latest patch, as committed to HEAD.
fixed in cvs.