https://bugs.kde.org/show_bug.cgi?id=434949
Fabian Vogt <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|[email protected] |[email protected] Ever confirmed|0 |1 Product|systemsettings |frameworks-kglobalaccel Component|kcm_keys |general Status|REPORTED |CONFIRMED Version|5.21.3 |5.90.0 --- Comment #22 from Fabian Vogt <[email protected]> --- Now that we have https://invent.kde.org/qt/qt/qtbase/-/merge_requests/27, the shortcut can be managed properly, but kglobalaccel can't handle it properly. There is no explicit mapping for XK_Eacute, just the lower case XK_eacute: key <AE02> { type= "FOUR_LEVEL", symbols[Group1]= [ eacute, 2, asciitilde, oneeighth ] }; XK_Eacute can still be reached with CapsLock (https://gitlab.freedesktop.org/xorg/lib/libxcb-keysyms/-/blob/691515491a4a3c119adc6c769c29de264b3f3806/keysyms/keysyms.c#L173): * The Shift modifier is off, and the Lock modifier is on and is interpreted as CapsLock. In this case, the first KeySym is used, but if that KeySym is lowercase alphabetic, then the corresponding uppercase KeySym is used instead. However, this is not handled by xcb_key_symbols_get_keycode, and so it fails to return any keycodes for XK_Eacute. I don't know whether that's a bug or by design. The code/algorithm appears to be a copy from Xlib. This can be worked around by trying the lowercase keysym in such cases: if(keySymX < 0xff && QChar(keySymX).isUpper()) keySymX = QChar(keySymX).toLower().unicode(); Then the grab is done correctly, but press events get translated to Meta+é instead of Meta+Ê (though misleadingly still printed as Meta+Ê due to QKeySequence(keyQt).toString()). This is because symXModXToKeyQt in kwindowsystem only converts a-z to upper, not including others. Extending that to 0xFF makes Meta+Ê shortcuts work properly. -- You are receiving this mail because: You are watching all bug changes.
