Bug 342493 - Accentuated characters used in shortcuts are considered as uppercase
Summary: Accentuated characters used in shortcuts are considered as uppercase
Status: RESOLVED UNMAINTAINED
Alias: None
Product: systemsettings
Classification: Applications
Component: kcm_khotkeys (show other bugs)
Version: unspecified
Platform: Debian testing Linux
: NOR normal
Target Milestone: ---
Assignee: Michael Jansen
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-01-05 00:58 UTC by chicco
Modified: 2024-03-04 19:42 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description chicco 2015-01-05 00:58:47 UTC
When setting a shortcut containing an accentuated letter like 'é' it is recorded as the uppercase version of the letter: 'É'. When the shortcut is replayed, it is not recognized. yet it is recognized when caps-lock is on.

Notice that I'm using an azerty keyboard where 'é' and '2' are on the same key.

Reproducible: Always

Steps to Reproduce:
1. set the META-é shortcut to some action
2. save
3. press META-é
4. press caps lock (set it on)
5. press META-é

Actual Results:  
3. no effect
5. performs the action

Expected Results:  
3. performs the action
5. performs the action
Comment 1 arnco 2017-02-15 12:57:07 UTC
Hi,

Same problem here with the Ctrl+é shortcut, french azerty Keyboard on a 2012-MacBook Pro running Linux Mint 18 KDE.

Even when caps lock is on, the shortcut isn't recognzed.
Comment 2 drbb 2020-10-20 08:34:32 UTC
Same for me (Plasma 5.19.5, KDE Framework 5.74.0). Caps lock has no effect.
Comment 3 David Edmundson 2020-10-20 22:04:49 UTC
and just to confirm, this didn't used to be the case in previous releases?
Comment 4 drbb 2020-10-21 07:57:56 UTC
(In reply to David Edmundson from comment #3)
> and just to confirm, this didn't used to be the case in previous releases?

Personally, I haven't noticed. This is the first time I had the necessity to assign a shortcut to those keys.
Comment 5 frais64 2021-10-11 13:47:55 UTC
I have the exact same problem using the latest kde version on arch linux.
Comment 6 kde 2023-01-16 00:20:04 UTC
Same issue here (KDE Plasma 5.20.5): I would like to set up KDE just like i3 and use Meta+1[&] to switch to workspace 1, Meta+2[é] to switch to workspace 2 and so on, but it doesn't work for keys 2[é] 7[è] 9[ç] 0[à] as explained before.

I tried to update the configuration file (.config/kglobalshortcutsrc) manually but with no success.

This bug has been open for over 8 years now.
Comment 7 Nate Graham 2024-03-04 19:42:09 UTC
As announced in https://pointieststick.com/2023/07/26/what-we-plan-to-remove-in-plasma-6/ and https://community.kde.org/Plasma/Plasma_6#Removals, I'm afraid KHotKeys has reached end-of-life in Plasma 6. Accordingly, all bug reports and feature requests for it must be closed now.

Most of what KHotKeys could do can already be done with the newer KGlobalAccel system in Plasma 6. A few features such as mouse gestures and triggering conditions based on changes to window states are not yet implemented in the new system. These will be added in the future if and when resources materialize for them, and/or when a kind soul submits patches to implement them! :) Meanwhile, the 3rd-party "Mouse Actions" app (https://github.com/jersou/mouse-actions) may be usable for implementing your own mouse gestures again.

Thanks for your understanding, everyone.