Created attachment 53344 [details] `setxkbmap us && xmodmap .xmodmap` Version: unspecified (using KDE 4.4.5) OS: Linux I want to use xmodmap to map my keys to my liking. I use Mode_switch (which I mapped to left control) as 3rd level (in addition to the 2nd level through Shift); however, when I hold Mode_switch and press a button which has a symbol defined to the 3rd level, it is no inserted (or rather, not considered at all). This happens only in application that use the Kate Part (like Kate, KWrite, KDevelop and Kile); it works perfectly well in other applications (even at other places in Kate). Only the main text editor area is affected. Reproducible: Always OS: Linux (x86_64) release 2.6.32-5-amd64 Compiler: cc
Qt doesn't seems to like shortcut with Mode_switch Please try this patch diff --git a/src/gui/kernel/qkeymapper_x11.cpp b/src/gui/kernel/qkeymapper_x11.cpp index a30454c..c0ddfd4 100644 --- a/src/gui/kernel/qkeymapper_x11.cpp +++ b/src/gui/kernel/qkeymapper_x11.cpp @@ -285,7 +285,7 @@ QList<int> QKeyMapperPrivate::possibleKeysXKB(QKeyEvent *event) // always use them when determining the baseKeySym) KeySym baseKeySym; uint consumedModifiers; - if (!XkbLookupKeySym(X11->display, xkeycode, (xmodifiers & (LockMask | qt_num_lock_mask)), + if (!XkbLookupKeySym(X11->display, xkeycode, (xmodifiers & ((LockMask | qt_num_lock_mask) | ~0xFF )), &consumedModifiers, &baseKeySym)) return QList<int>();
I could not try the patch yet; however, I tried to work around the issue. Instead of using Mode_switch I tried to use ISO_Level_Shift. While it works a bit better (some of my shortcuts work now), I still have problems, possibly related to the combination of ISO_Level3_Shift and Shift. Again, the problem manifests in the Kate Part only. There must be something in Kate Part, that handles the keyboard layout differently than other Qt components.
We do really nothing special with key shortcuts and follow the normal Qt API. If that problem persists with current Qt versions, please report a Qt bug.
There really is a bug in Qt here. See: https://bugreports.qt-project.org/browse/QTBUG-15319 https://bugs.kde.org/show_bug.cgi?id=306316 I've tested the patch provided by Pascal Létourneau but I don't understand it. How can "| ~0xff" make XkbLookupKeySym() use another layout for the conversion keycode -> keysym? Any explanation will be appreciated.
I've forgotten the most important: the patch solves the bug.
See my explanation here: https://bugreports.qt-project.org/browse/QTBUG-15319
@David: Do you see any change to get such a patch into Qt4? @Aurelien: It's good to see having a patch for Qt4. With luck, it is even accepted (but you may have to file a merge request yourself on the qt project, http://qt-project.org/wiki/How_to_Apply_Git_Merge_Request). Or talk to the Qt people in IRC. In Qt5, the code seems to have changed quite a bit, and the code peace the code patches does not exist anymore. So it might be that it's fixed in Qt5 anyway, which eventually will resolve this bug as well.
I'm no expert with that stuff, but the patch looks reasonable to me. The best way to find out if it can go into Qt, is to submit it in gerrit :-) 4.x isn't closed, you can definitely get bugfixes in.
I've just pushed the patch to Gerrit: https://codereview.qt-project.org/44458 Concerning these Merge Requests, I'll try to understand what it is in the next days (this is my first Qt patch). Next week I'll check the code of Qt5. I've read somewhere that Qt5 is now always built with QT_NO_XKB anyway (in this case the patched line is deadcode in Qt5).
Qt5 seems to contain nothing about Xkb. I managed to build it (much easier than Qt4 by the way) and my small test application for demonstrating the bug (see bug #306316), but I could not reproduce it. So this bug isn't in Qt5.
Concerning the "merge request", I don't get it, sorry. What branches should we then request to be merged?
Well, if the bug isn't in Qt5, then the merge request should only be for qt/4.8, which is exactly what you did. Now we need to find a Qt developer to approve it....