I posted this in the KDEmod (Chakra) forum, but since I didn't get any response there I hope someone will help me here.

Here's the original message:
8 Regional & Language -> Keyboard Layout. Choose "Enable keyboard layouts".
2. Your preferred layout should already be in the list. If not, add it. Then add another layout and choose variant 'Dvorak'. Make sure the new layout is below your preferred.
3. Open an application to test the shortcuts. I use Dolphin as an example.
4. Switch to Dvorak by clicking on the flag in system tray.
5. Press a shortcut, for example Ctrl+L, as if you were typing QWERTY.
6. Report what happens. If the shortcuts are in Dvorak, it should open a new window. Otherwise, as in my case, it'll focus the location bar.

Thanks!

--

[1] Sure I could assign the command to a hotkey and be happy, but I want to fix this properly. If it's a bug in KDE 4.2, I'm going to report it.

-------- >8

I use Arch Linux with KDEmod 4.2. The xorg-server version is 1.5.3-4.

OK, I just found that Qt apps also have this problem (tried Qt Assistant and Shaman), while GTK apps work fine (Firefox and Pidgin). This sounds farfetched, but could it be a Qt4 bug?

If the keyboard layout set through System Settings works for Gtk apps, but not for Qt4 apps, then it could very well be a bug in Qt. You may wish to ask on one of their mailing lists about this.

Mail sent to Qt mailing list, I'll keep you updated.

So here is the promised update:

I never got any replies on Qt-Interest ML. However, another person with the same problem found this thread, and he/she investigated deeper into the problem. Thanks to M. Vefa Bicakci, we now know the following (partially quotes from the mails I received):

1. There's a bug in Qt that affects local shortcuts (such as Alt- ). I was also sent a patch that fixes it (applies cleanly to Qt 4.5.1). Not sure if it's been fixed in Qt' development tree, but hopefully it is.

2. The global shortcut bug is not KDE's fault, but rather "a limitation in the X11 infrastructure". When forcing the keymap change with setxkbmap, "a MappingNotify XEvent is generated by the X server, and when a
properly coded window manager sees that event, it updates its XGrabKey configuration. This also explains why KDE 3.5 worked properly: it used to change the keymap by brute force like the second example command. [setxkbmap]"

But if you switch layouts by e.g. pressing Alt-Shift, "XGrabKey continues to observe the keyboard as if the US keymap group was active."

The setxkbmap command should work properly in KDE trunk (but not 4.2 because of a commented line). Next thing to do is to talk to someone who's experienced in X11 and see if point 2. is correct, and if it can be fixed.

I still have this problem with the latest release of both KDE and Qt...
Is it fixed for you ?
It is strange such a bug survived over two years...

Could you provide the patch that fixed it for you ?

Thanks !

EDIT : I found a link describing this exact problem, quite precisely :

http://helgo.net/simon/hacking/shortcut.html

It seems there is no standard on shortcut interpretation... However, Qt's way sure seems broken, as it does not take the active key group into account at all.