Bug 252594 - Accentuated letters in keyboard shortcuts get capitalized
Summary: Accentuated letters in keyboard shortcuts get capitalized
Status: RESOLVED DUPLICATE of bug 375518
Alias: None
Product: frameworks-kxmlgui
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: unspecified
Platform: Debian unstable Linux
: NOR normal
Target Milestone: ---
Assignee: kdelibs bugs
Depends on:
Reported: 2010-09-27 23:58 UTC by Édouard Siha
Modified: 2021-03-26 16:08 UTC (History)
15 users (show)

See Also:
Latest Commit:
Version Fixed In:

Shortcuts using accent keys (38.63 KB, image/png)
2019-05-30 22:13 UTC, lukas.knapek

Note You need to log in before you can comment on or make changes to this bug.
Description Édouard Siha 2010-09-27 23:58:59 UTC
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.
Comment 1 Sami Boukortt 2012-03-14 22:07:29 UTC
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).)
Comment 2 g@oknaj.eu 2013-03-04 20:45:19 UTC
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.
Comment 3 Xzorg6 2013-05-01 18:42:57 UTC
I can confirm that bug in KDE 4.10.2 on a french keyboard layout.

Still not possible to configure "Alt+é" as a shortcut.
Comment 4 Anne-Marie Mahfouf 2013-05-11 08:29:52 UTC
*** Bug 260260 has been marked as a duplicate of this bug. ***
Comment 5 Anne-Marie Mahfouf 2013-05-11 08:40:08 UTC
*** Bug 167428 has been marked as a duplicate of this bug. ***
Comment 6 Anne-Marie Mahfouf 2013-05-11 08:41:02 UTC
Reproduced with Alt+é and confirmed
Comment 7 Rafael 2013-10-16 16:00:14 UTC
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).
Comment 8 lukas.knapek 2019-05-30 22:13:28 UTC
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.
Comment 9 lukas.knapek 2019-05-30 22:15:11 UTC
Forgot to mention, activating Caps Lock before trying out the shortcuts does not work either, unfortunately.
Comment 10 bugs.kde.org 2019-12-31 21:42:54 UTC
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
Comment 11 mikael.mantel 2020-08-18 09:29:58 UTC
I have the same problem.
Why this bug is still there ? This is too old, It's not a quick fix ?
Comment 12 Christoph Feck 2020-09-09 10:25:43 UTC
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.
Comment 13 Habib KDE 2020-09-25 14:24:28 UTC
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.
Comment 14 Nate Graham 2021-03-26 16:08:26 UTC

*** This bug has been marked as a duplicate of bug 375518 ***