Version: 4.4 (using KDE 4.4.5) OS: Linux Since I switched from KDE3 to KDE4, I have never been able to set properly keyboard shortcuts using accentuated letters. When associating such a shortcut with an any action, KDE thinks I typed the corresponding higher case letter. For example, when trying to associate Meta+é to "Switch to Desktop #2", KDE records Meta+É as the entered shortcut. Meta+É then works as the recorded shortcut, but Meta+é does not. Reproducible: Always Steps to Reproduce: Switch to an azerty french layout. Configure any shorcut of any KDE app to use a keyboard shortcut involving an accentuated letter. Actual Results: KDE records the shortcut as if the corresponding higher case letter was pressed. Expected Results: KDE should record the shortcut with the lower case accentuated letter that was typed. I noticed that the presence or absence of modifiers (Meta, Shift, ...) have no importance whatsoever. Whenever typing an accentuated lower case letter when defining a shortcut, KDE records the corresponding higher case letter. I tried with letters é, è, ç, à and ù, with and without modifiers, assigning to different actions, all of which give the same result.
I can confirm that bug in KDE SC 4.8.1. An action to which “Meta+B” (for example) is assigned can be triggered by either Meta+B or Meta+b. However, if the shortcut is “Meta+Ê”, then ê *has* to be upper case (which effectively means that Caps Lock has to be on: if Shift is used instead, the shortcut is interpreted as “Meta+Shift+Ê”), which suggests to me that KGlobalAccel is unable to turn the shortcut back to lower case (though I am not sure at all about it). (Sorry for my English, it is not my native language (as you may have guessed from my use of a keyboard layout with “ê” in it).)
I can confirm on Fedora 18, KDE 4.9.5 on a french (apple - laptop) keyboard. Trying to setup Ctrl - é actually binds Ctrl - É, and neither Ctrl - é or Ctrl - É works as expected. Note that this is probably a duplicate of https://bugs.kde.org/show_bug.cgi?id=260260 Please change the Status to Confirmed.
I can confirm that bug in KDE 4.10.2 on a french keyboard layout. Still not possible to configure "Alt+é" as a shortcut.
*** Bug 260260 has been marked as a duplicate of this bug. ***
*** Bug 167428 has been marked as a duplicate of this bug. ***
Reproduced with Alt+é and confirmed
Maybe a cross-post, but does have to do with this: In "English (US, international with dead keys)" layout, it's impossible to use binding alt+`. That's probably because in this layout ` is produced by typing `+space. Whenever I do this, KDE's shortcut register a scrambled unicode character instead of `. That also happens with other composed keys like " and '. Shortcuts should ignore this aspect of these keys and use straight value (what would be the <key>+space value).
Created attachment 120419 [details] Shortcuts using accent keys I have recently started using KDE and ran into this bug. The attachment shows my keyboard shortcuts that I usually use to switch between desktops. In KDE 5.15.5, any shortcuts using accent keys (i.e. ěščřžýáíé...) are ignored completely no matter if used alone or in combination with a modifier key (e.g. Meta+ě doesn't work either). The same shortcuts work well in Gnome and Cinnamon. Xev appears to detect the keys correctly, so I'm at loss as to where the error might be.
Forgot to mention, activating Caps Lock before trying out the shortcuts does not work either, unfortunately.
As a workaround, since this bug has not been fixed, it is possible to use an external tool to handle the keyboard sequence. For instance, to switch to the 2nd workspace with Win+é, one may use sxhkd with the rule: super + eacute xdotool set_desktop 1
I have the same problem. Why this bug is still there ? This is too old, It's not a quick fix ?
It is not a quick fix, because multiple components (X11 xkbd, Qt, several frameworks) are involved. It requires a contributor who is able to debug the interaction of all components. Also, this ticket seems to mix global shortcuts and in-application shortcuts, which are actually completely different code paths. Reassigning to kxmlgui frameworks, where the configuration of in-application shortcuts is handled.
Operating System: Fedora 32 KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.70.0 Qt Version: 5.14.2 Kernel Version: 5.8.10-200.fc32.x86_64 OS Type: 64-bit Keyboard Layout: fr I am facing the same problem I've tried the workaround mentioned above with sxhkd but I get this error. Could not grab key 11 with modfield 64: the combination is already grabbed. Could not grab key 11 with modfield 80: the combination is already grabbed. Could not grab key 11 with modfield 66: the combination is already grabbed. Could not grab key 11 with modfield 82: the combination is already grabbed. I even tried mingling with xmodmap no luck so far.
*** This bug has been marked as a duplicate of bug 375518 ***