Version: ��� (using KDE 3.2.2, (testing/unstable)) Compiler: gcc version 3.3.3 (Debian 20040401) OS: Linux (i686) release 2.4.25-1-686 I am using several layouts on my computer, and manage the switching only via the KDE layer - because I really like the sticky switching and the flag it provides. Because I am used to mapping the rwin key to cause the group toggle from the way it is set up on the Linux console (where I switch using the console-cyrillic Debian package), I wanted to set up the same thing over in KDE. In my XF86config, I *do not* do any fancy layout mgmt: Section "InputDevice" Identifier "Generic Keyboard" Driver "keyboard" Option "CoreKeyboard" Option "XkbRules" "xfree86" Option "XkbModel" "pc104" Option "XkbLayout" "us" EndSection The natural way (using the path of the least resistance through the KDE GUI) didn't work, but I nevertheless achieved the desired result using an ugly hack. Detailed description of both follows. In layouts, select several layouts (> 1). (I tested with 2-5 different layouts out of the set of US, US intl w/dead keys, Hebrew, Russian, Spanish, French, Italian and German.) I also enabled the sticky switching. These things are common to both the working and the non-working solution. Now the intuitive thing that doesn't work: on the xkb options tab, select "enable xkb options", "reset old options", then, in the "group switching" subtree, select "Right Win-key changes group". Apply the things, and try the Right Win-key. It doesn't work, but this is probably just an instance of http://bugs.kde.org/show_bug.cgi?id=59442 So kill KDE and restart, and verify the options are there in the kxkb. Right Windows key still doesn't do it. Ouch. Now the ugly workaround comes. Disable back the "group switching" subtree selection, and in the "Third level choosers" subtree set the Right Win-key to choose the third level. Now, apply the changes. Go to the keyboard shortcuts via your control panel (`kcmshell keys' from the command line). There, in the Global Shortcuts tab, add to the "Keyboard/Switch to next keyboard layout" shortcut a custom shortcut - and press the rwin key recording it. You should see ISO_Level3_Shift now as the alternative combination. Apply the changes. That's not all. Unfortunately, until you log out and log back in (maybe it's possible to just restart smth inside KDE, but I didn't investigate this), at least on my machine, with the default modifiers scheme, pressing rwin raises the application menu. When you log back in, you finally get what you wanted - right win changes the group, you can verify it with the flag icon in the tray, and it actually changes the keyboard layout. Without the level3 thing, this won't work because then rwin will just stay a modifier key, and currently the shortcut recording doesn't allow for modifiers-only shortcuts. Overall, the internationalization UI is very counterintuitive right now. It's a pity that there is no way to learn about the group switching shortcut from within kxkb, and vice versa, about kxkb when configuring the keyboard shortcuts. Here, however, I am unable to provide constructive critics because I'm pretty dumb in the UI design. The bug is consistent, and doesn't depend on which language and primary locale (I didn't try UTF-8-based locales, though) the local user uses.
Debian twin bug xref: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=257984
do you use 'Include latin group' option? Because if you don't, in XFree starting 4.3.0 there's only one group in each layout by default (unless you changed options in /etc/X11/xkb/rules/xfree86) and thus group switching does not make much sense.
Andriy, thanks for your prompt reply. On 7 Jul 2004, Andriy Rysin wrote: > do you use 'Include latin group' option? Because if you don't, in XFree > starting 4.3.0 there's only one group in each layout by default (unless > you changed options in /etc/X11/xkb/rules/xfree86) and thus group > switching does not make much sense. The bug behavior has been verified with and without the "Include latin group" simultaneously selected on each layout. Between the attempts, after the kxkb changes were accepted, kde was restarted. The only effect of this option is that one can do "Ctrl+..." even with the non-Latin layout selected, and it will work; with and without it, kxkb still ignores the requested group toggle behavior of rwin. Vassilii
Now I see what you mean. The problem is that by default or in your X configuration X treats Right-Win as a modifier so you cannot assign shortcut just to Right-Win. When you switch Right-Win to 'xkb group changer' then is becomes standalone key wich you can bound to layout switching. It's not a problem of kxkb - I can transfer this issue to general kde but it's just the nature of X and I am not sure it can be helped easily. The main problem here is that X and KDE are different products and don't integrate too tightly. Lubos, you may be more familiar with this, could you please comment this issue? Thanks.
*** Bug 44808 has been marked as a duplicate of this bug. ***
*** Bug 83958 has been marked as a duplicate of this bug. ***
> Now I see what you mean. The problem is that by default or in your X > configuration X treats Right-Win as a modifier so you cannot assign > shortcut just to Right-Win. Correct. It is the default - I didn't do any local maps change. > When you switch Right-Win to 'xkb group > changer' then is becomes standalone key wich you can bound to layout > switching. This is the nature of my workaround hack. > It's not a problem of kxkb - I can transfer this issue to I still think there is a problem with the kxkb because its UI is misleading. If there is an option there that suggests that if one selects it, it would be possible to use rwin as the group toggle, it is only natural that an average user (that doesn't know a modifier from a normal key) will be happy to select it and then become frustrated because of it. Also, there is this ugly separation between the shortkuts configuration and the switching configuration in kxkb, I am sure a lot of people have only seen one but not the other. > general kde but it's just the nature of X and I am not sure it can be > helped easily. The main problem here is that X and KDE are different > products and don't integrate too tightly. Lubos, you may be more > familiar with this, could you please comment this issue? Thanks.
Well, the point here is that it works for AltWin and it may work for Alt+Shift but it may not work for Ctrl+Shift or Ctrl+Alt, so we can not make this as a standard option for an average user. The ugly workaround - that's what it is. I put 'Xkb option' to kxkb configuration panel because X implementation is pretty complex and cumbersome in xkb area and I just wanted some 'advanced options' to be accessible to the (advanced) people who want to use them. It may happen to enable some missing KDE features but it was not designed to do so and it's not possible to make this standard. I could remove 'xkb options' altogether but I think that many people use it for other needs and they will not be happy about that. The only proper way is to tweak kdelibs (?) to be able to use modifiers as shortcuts without ugly hacks. Thus kxkb will not be directly involved into proper solution.
> Well, the point here is that it works for AltWin and it may work for > Alt+Shift but it may not work for Ctrl+Shift or Ctrl+Alt, so we can > not make this as a standard option for an average user. The ugly > workaround - that's what it is. Agreed :) > I put 'Xkb option' to kxkb > configuration panel because X implementation is pretty complex and > cumbersome in xkb area and I just wanted some 'advanced options' to be > accessible to the (advanced) people who want to use them. It may > happen to enable some missing KDE features but it was not designed to > do so and it's not possible to make this standard. I could remove 'xkb > options' altogether but I think that many people use it for other > needs and they will not be happy about that. Indeed it would be very gruesome if this is removed altogether. > The only proper way is > to tweak kdelibs (?) to be able to use modifiers as shortcuts without > ugly hacks. Thus kxkb will not be directly involved into proper > solution. I wonder if kxkb could transparently do smth along the lines of the hack - check if it is a modifier first, then, if it is, verify that no shortcuts using it exist (otherwise give a warning they will no longer be accessible). Then, transparently remap the modifier into some unused code, and then use that code as the switching shortcut. Obviously, this would be much more than is possible during the current approach that just takes the GUI selections and blindly translates them into a setxkbmap cmdline.
Actually the trick whether called ugly or not is very valuable to me. Thanks.
I think it should be possible to make the shortcut dialog accept only modifier key(s) as the shortcut, and modify KGlobalAccel accordingly. It probably doesn't make much sense for other apps than kxkb though. I don't understand what the rest of the bugreport is about, too xkb-ish to me :(.
Is there a way to do a similar trick with "CAPS"? The difficulty for me is that "CAPS changes group" doesn't work just like the "Right Win changes group"; however, there is no CAPS option in the level3 chooser key selection. (If you are curious, I am wokring on a laptop at this where there is only one (left) win key present; I worked it around by assigning the level3 switching to the right CTRL, but it isn't very neat as I keep hitting it by accident :( ).
If one adds the German ("de") keyboard layout, the workaround I had earlier described in this thread works for switching TO the German keymap, but doesn't work to switch back FROM the German keymap. (Tested with KDE 3.5, debian Etch + some unstable stuff on the machine).
In KDE4 kxkb switches groups instead of layouts so this should not be a problem any more.