Bug 256653

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....