GNOME Bugzilla – Bug 78288
gkb loads US keymap by default
Last modified: 2009-08-15 18:40:50 UTC
Using beta3, gkb applet, version 1.98.0, on Solaris 8, Adding applet to panel disables use of pipe symbol in terminal. To Reproduce: 1) Open a terminal, type ls | grep anything. 2) Add the gkb applet to the panel. 3) Open another terminal, and again type ls | grep anything. Pipe symbol key doesn't work.
Re-titling with what is probably more correct. I'm really not sure there is a GNOME level solution for this, though.
I consider this one quite a high priority fix, as after the applet is added to the panel, the only solution is to reboot, not even removing the applet and logging out and in again enables use of the pipe on keyboard.
Right, but the fix is not in gkb- I /think/ it is in sun's shipping/packaging of gkb. Anyone from gnome-applets care to discuss/comment? Or should this be a build-time test?
I think what is happening is, that when the gkb-keyboard-applet starts it automatically loads in a US keyboard mapping without warning the user, if users are on UK keyboards they have their pipe symbols moved and other useful keys without warning. It would be better if this action were disabled, and the applet attempted to determine which keyboard mapping the user has when it starts up and then load that one instead of default US.
Putting on GNOME2 milestone though it may not get fixed. Perhaps the easy solution is to not load the keymap on startup and let the user change it to whatever he/she wants
I plan to make a wizard what lauch at first start. I've got a working glade now, I can make it soon.
A wizard is a major overkill. A simple dialog would work perfectly fine. I don't think the applet should popup anything when added though. It's also probably too late for these changes. Shooby: can the applet query what the current keyboard is? Or can it just not set the keyboard when first started? There's a UI/string freeze beginning very soon, so we don't have much time to make changes. Also see bug #80354 for a gui enhancement that might make it more obvious for users how to setup the applet in the future.
*** Bug 79284 has been marked as a duplicate of this bug. ***
I made a fast fix for this probem. Send me a negotiation or a fixed version of this attached patch. This patch also needs a gkb.png in the flag dir to be the default flag.
Created attachment 8350 [details] [review] The proposed hotfix patch for this bug
What does the patch do? I'm not sure I understand what changes you've made
When the user runs this applet for the first time, GKB makes a "default keymap" (~/.gkb_default.xmm, I know it's ughly a bit) for the user from the current keyboard layout and loads it by default instead of the US keymap. As I said it's a hotfix.
*** Bug 81388 has been marked as a duplicate of this bug. ***
Shooby: should the applet restore the default keyboard when exiting?
Bruhu... somebody wants to remove my applet ;(((( OK, I think the idea is good. I gonna make it.
This problem also exists on Solaris Intel but the consequences of the US keyboard being selected leaves the user with a more or less disfunctional keyboard, all numeric keys and the <CR> do not work.
I have a problem that ~/.gkb_default.xmm doesnt work on my Solaris m/c. On adding the gkb-applet to the panel, i get the following error "The keymap switching command returned with error!". On further inspection, i found that the ~/.gkb_default.xmm file is not being generated. Attaching a patch which fixes this. What the patch does is it gets the user home dir by calling g_get_home_dir () rather than using ~/
Created attachment 8774 [details] [review] Proposed patch
The user can delete the default keymap, but there is no way to add it back. This can be a problem. Maybe the user should not be allowed to delete the default keymap.
Shivram: I agree that the user probably should not be able to delete the default. Shooby: what do you think?
Agree. Will this produce uncompatibility for any supported platform? I think on Unix platforms this will be ok.
So how do we do this: Do we popup a dialog if the user tries to delete the default keymap ? Do we disable the Delete button in the preferences dialog if the default keymap is selected ? I thought disabling the Delete button should do it. Maybe the Edit button should be disabled too. Shooby: If disabling the buttons is ok with you i can make the changes.
Attaching a patch anyway :-) The patch disables the Delete and Edit buttons in the preferences dialog if the default keymap is selected. The patch also restores the default keymap when the applet is removed from the panel.
Created attachment 8851 [details] [review] Proposed patch
No way! You don't understand my program :-( I don't want to keep the default keymap. I do not use that keymap entry when restoring the original keyboard layout. User can make a different layout combination, what do not contains the default map. I use 3 keymap what is not the X's default keymap, and I don't want to switch between four keymap just because there is a fourth what is unusable for me. Why do you want to keep that entry? It's just because those users who wants to use this applet with good defaults.
The default xmodmap file will not be deleted when user press the Delete button. I plan to catch the exit of the applet and make a system("xmodmap ~/.gkb_default.xmm"); simply. I have problems because applet's destroy is not called as I recognised, that's why I didn't fix this problem weeks ago. But when I will find the way to catch the applet removal event I will be able to reset the default keymap after user removes the applet from the panel.
True the default keymap file is not being deleted and default keymap can be restored on exit. But consider the following case 1. Using the xmodmap command i have a custom keymap setting. 1. On loading the applet, this keymap setting would become my default keymap and is kept in the .gkb_keymap.xmm file. 2. Now i click on preferences and delete the default keymap entry. 3. Now if i want to revert back to my default keymap, the only way i can get back my original keymap is by running the xmodmap ~/.gkb_keymap.xmm command or by removing the applet (when the code for restoring the keymap is added ) Maybe the user should be given an option to somehow add back the default keymap to the layout.
If it's OK I could make a keyprop file for this default layout with International settings. In the help there will be a section for users who want to use special keymaps. Can I commit the keyprop file?
Nice idea Shooby. This would clear up most things. The only thing then left would be restoring the default keymap on exit. Shooby, doesnt adding the code for restoring in gkb_destroy () work. Works fine for me on my machine. Hmm.. may be not if more than one instance of the applet is running and if one is removed. Ofcourse if the applet is killed explicity then nothing much can be done. Is there anyway we can execute the system() call during factory shutdown ?
(Adding Sunray error) Solaris sparc 8 update 4, sunray server, gnome-2.0 prebeta1 On sunray server the selection of the US keymap messes up all keys except the numeric keys (i.e. 01234 etc.) on the keyboard.
tested build built from source 31st may on Intel Solaris - the gkb applet is working fine - default is "gkb" if user clicks on applet it changes to "us" and there are NO adverse effects when "us" keyboard is selected.
Robert: One of the reasons why selection of US keymap fails could be that the keyboard for the Sunray server is a Sun USB keyboard. Could you please verify this by "kbd -t" command. I faced the same problem on a SunBlade 100 machine with a Sun USB keyboard. The appropriate keymaps for USB keyboards are available. You can add that from the preferences dialog. Add->English->United States->US Sun USB keyboard. And selecting this keymap should work fine.
Shooby: Would you be committing the keyprop.in file for the default layout? If you need anything to be done, i'll be glad to help.
just noticed that the gkb applet causes the "Return" key to lose its function on a Dell Optiplex GX110 machine - the function of "carriage return" is moved from the "Return" key to the "#" (hash) key. This is only present on the Dell Optiplex GX110 - I also tried it on a gateway 2000 machine with no problems... What would cause this? What machine specific features does gkb applet depend on?
Committed the Default.keymap.in and Makefile.am to descs dir. Please try out under solaris and commit to descs.sun if works.
I have tried out the Default.keyprop file under Solaris. It works fine. But i had this little doubt in my mind. The name and label is different from the Default keymap we first load. The name is "Original keymap" and label is "dvr" in the file. The default keymap we load has "Gnome keyboard default" as the name and "gkb" as the label.
FIX in CVS, please check and make another note or close the bug
waiting for build....:)
this was tested on a Dell Optiplex GX110 with solaris and a gnome build from CVS 19th June. The problem is still there although the enter key functionality has now moved to the \ key.
Hey Shane: why don't we close this bug and open a new one for the remaining issues? I think this bug has wandered quite a bit. I'm not clear anymore as to what the problem is now.
Kevin: that's ok with me - i'll close this as original problem fixed, new bug opened for intel specific problem... opening a new bug #87124
fix verified (pipe symbol works)
closing