Bug 434949 - Custom shortcuts containing accented keys ("é" "è" "ç" "à") aren't working on X11
Summary: Custom shortcuts containing accented keys ("é" "è" "ç" "à") aren't working on...
Status: CONFIRMED
Alias: None
Product: frameworks-kglobalaccel
Classification: Unclassified
Component: general (show other bugs)
Version: 5.90.0
Platform: Archlinux Packages Linux
: NOR normal
Target Milestone: ---
Assignee: kdelibs bugs
URL: `
Keywords:
: 448154 (view as bug list)
Depends on:
Blocks:
 
Reported: 2021-03-25 19:28 UTC by 80p3fy75dc
Modified: 2022-06-28 17:13 UTC (History)
8 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 80p3fy75dc 2021-03-25 19:28:07 UTC
I know this bug has been reported many times in the last ten years:

https://bugs.kde.org/show_bug.cgi?id=318666
https://bugs.kde.org/show_bug.cgi?id=167428
https://bugs.kde.org/show_bug.cgi?id=176514
https://bugs.kde.org/show_bug.cgi?id=177321
https://bugs.kde.org/show_bug.cgi?id=182434
https://bugs.kde.org/show_bug.cgi?id=187730
https://bugs.kde.org/show_bug.cgi?id=252594
https://bugs.kde.org/show_bug.cgi?id=260260
https://bugs.kde.org/show_bug.cgi?id=320612
https://forum.kde.org/viewtopic.php?f=17&t=169819
https://www.reddit.com/r/kde/comments/fjmn1g/some_shortcuts_not_working/

but it's 2021 and it's still not fixed. So here's another bug report because why not.

I can replicate it both on Arch Linux and Gentoo with Plasma 5.21.3 / KDE Frameworks 5.80.0.


STEPS TO REPRODUCE
1. Switch to French keyboard layout in Hardware > Input Devices > Keyboard > Layouts (any variant, doesn't matter)

2. Try to assign some custom shortcuts with accented keys in "Shortcuts" section,
for instance:
Kwin > Switch to Desktop 2 > Meta+É
Kwin > Switch to Desktop 7 > Meta+È
Kwin > Switch to Desktop 9 > Meta+Ç
Kwin > Switch to Desktop 10 > Meta+À

3. Click on "Apply"

OBSERVED RESULT

The shortcuts containing an accented key won't work, i.e. you'll never be able to switch to Desktop 2 using "Meta+É" or to Desktop 9 using "Meta+Ç". Nothing happens. The other shortcuts like "Meta+&" to switch to Desktop 1 or 'Meta+"' to switch to Desktop 3 work just fine.


EXPECTED RESULT

The shortcuts containing an accented key should work like the others.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Plasma 5.21.3 / KDE Frameworks 5.80.0
(available in About System)
KDE Plasma Version: 5.21.3
KDE Frameworks Version: 5.80.0
Qt Version: 5.15.2
Comment 1 Nate Graham 2021-03-25 21:04:29 UTC
This one is actually a duplicate of none of those, but rather Bug 414501.

*** This bug has been marked as a duplicate of bug 414501 ***
Comment 2 80p3fy75dc 2021-03-25 22:00:16 UTC
(In reply to Nate Graham from comment #1)
> This one is actually a duplicate of none of those, but rather Bug 414501.
> 
> *** This bug has been marked as a duplicate of bug 414501 ***

Huh?

I cannot reproduce bug 414501. Accented characters (é è ç à) work just fine here in Workspace Behavior > Desktop Effects search bar.

All the links I mentioned describe the exact same issue that I reported, namely AZERTY keyboard/keymap users who cannot assign a shortcut with accented keys.
Comment 3 Nate Graham 2021-03-26 03:53:28 UTC
You're right, my mistake. Sorry about that.

Is this just when setting shortcuts? It's not seen anywhere else?
Comment 4 80p3fy75dc 2021-03-26 09:28:41 UTC
(In reply to Nate Graham from comment #3)
> You're right, my mistake. Sorry about that.
> 
> Is this just when setting shortcuts? It's not seen anywhere else?

No worries.

Yes, the accented keys work just fine everywhere else on my system including multiple KDE apps (Ark, Dolphin, Gwenview, Kate, Konsole, KCalc, KDE Partition Manager...). The only issue I'm having is when trying to assign shortcuts in System Settings > Shorcuts.

I noticed something else which is not specific to accented keys because it doesn't work with US keymap either: it seems that we cannot assign "Meta+Shift+<another_key>" to any action.

To reproduce, using regular English US keymap:

1. Go to System Settings > Shortcuts
2. Try to assign say "Meta+Shift+1" for "Window to Desktop 1" action
3. As you press the keys to define the shortcut, "Meta" and "Shift" appear in the box with the wheel, but as soon as you press "1", the shortcut ends up being "Meta+!". It seems that "Shift" key cannot be used in combination with another key which has two variants. Indeed, "Meta+Shift+<any_letter>" or "Meta+Shift+* (the * key being on the numpad and not having any variant) work just fine. But "Meta+Shift+7" will lead to "Meta+&" and so on.

Maybe I should create a distinct bug report for this?
Comment 5 Nate Graham 2021-03-26 14:47:59 UTC
It looks like it's actually Bug 375518, for which there is an open merge request to hopefully finally fix it. :) Maybe you can test?

https://invent.kde.org/plasma/kwin/-/merge_requests/786

> Maybe I should create a distinct bug report for this?
Yes please. :)

*** This bug has been marked as a duplicate of bug 375518 ***
Comment 6 80p3fy75dc 2021-03-26 18:16:49 UTC
(In reply to Nate Graham from comment #5)
> It looks like it's actually Bug 375518, for which there is an open merge
> request to hopefully finally fix it. :) Maybe you can test?
> https://invent.kde.org/plasma/kwin/-/merge_requests/786

Good catch! I wish I knew how to test it. Unfortunately I'm just a random end user and I'm not very familiar with Git and stuff.

I installed kwin-git from the AUR but for now it doesn't make any difference (I'm using X11).


> > Maybe I should create a distinct bug report for this?
> Yes please. :)

Done, see https://bugs.kde.org/show_bug.cgi?id=434988
Comment 7 Andrey 2021-03-26 18:26:57 UTC
It's important how these accented keys ("é" "è" "ç" "à") are generated on keyboard.
- If they are accessible as is, without any additional modifiers (on French layout) - that is definitely bug 375518.
- If they are accessible via Shift or some other modifiers (just to type them, without shortcuts) - that might be combination of bug 375518 and some other issue.
- If they are typing normally via dead keys - I'm not sure if that shortcuts was ever implemented at all.
Comment 8 80p3fy75dc 2021-03-26 19:02:39 UTC
(In reply to Andrey from comment #7)
> It's important how these accented keys ("é" "è" "ç" "à") are generated on
> keyboard.
> - If they are accessible as is, without any additional modifiers (on French
> layout) - that is definitely bug 375518.
> - If they are accessible via Shift or some other modifiers (just to type
> them, without shortcuts) - that might be combination of bug 375518 and some
> other issue.
> - If they are typing normally via dead keys - I'm not sure if that shortcuts
> was ever implemented at all.

"é" "è" "ç" and "à" can all be typed without any additional modifiers with French layout (AZERTY) 

"É" "È" "Ç" and "À" only require caps lock turned on, as you would expect. No additional modifiers either.

You can try yourself with a QWERTY keyboard and French layout using the numbers row:

Press "2" for "é" and "É"
Press "7" for "è" and "È"
Press "9" for "ç" and "Ç"
Press "0" for "à" and "À"
Comment 9 Andrey 2021-03-26 19:11:11 UTC
If it's bug 375518, I'm afraid I have a bad news - the second part of the fix is on Qt side, and even if it's accepted - we won't get full fix until we port to Qt 6.
That is something beyond technical issues.
https://codereview.qt-project.org/c/qt/qtbase/+/339895

But I see you are saying you run X11 - then it might be a different issue. Bug 375518 is wayland-specific as long as you first layout is US or like.
Anyway, I'll test the fix as soon I get a chance.
Comment 10 Andrey 2021-03-26 19:23:43 UTC
(In reply to 80p3fy75dc from comment #8)
> "é" "è" "ç" and "à" can all be typed without any additional modifiers with
> French layout (AZERTY) 
> 
> "É" "È" "Ç" and "À" only require caps lock turned on, as you would expect.
> No additional modifiers either.
> 
So does your report belong to upper or lower case, or both?
Comment 11 80p3fy75dc 2021-03-26 20:05:50 UTC
(In reply to Andrey from comment #10)
> (In reply to 80p3fy75dc from comment #8)
> > "é" "è" "ç" and "à" can all be typed without any additional modifiers with
> > French layout (AZERTY) 
> > 
> > "É" "È" "Ç" and "À" only require caps lock turned on, as you would expect.
> > No additional modifiers either.
> > 
> So does your report belong to upper or lower case, or both?

System Settings Shortcuts section will always register the upper-case ("É" ; "È" ; "Ç" "À") even if you press "é" ; "è", "ç" or "à".

This is true for any letter, at least for me. Press "Meta+m" and it will register as "Meta+M", press "Meta+y" and it will register as "Meta+Y" and so on.
Comment 12 80p3fy75dc 2021-03-26 21:08:00 UTC
I've just tried on Wayland and all the accented keys work just fine here. I can successfully switch to desktop 2 with "Meta+É", to Desktop 7 with "Meta+È", to Desktop 9 with "Meta+Ç", to Desktop 10 with "Meta+À"

So the issue is only occurring on X11.
Comment 13 Andrey 2021-03-26 21:18:21 UTC
Please note Global and Local (app-specific) shortcuts might behave differently.
bug 375518 is specific to Global shortcuts, so it's worth trying to override anything there, e.g KWin's standard Alt+` shortcut with Atl+È etc. and see if it works.
Comment 14 80p3fy75dc 2021-03-26 21:45:54 UTC
(In reply to Andrey from comment #13)
> Please note Global and Local (app-specific) shortcuts might behave
> differently.
> bug 375518 is specific to Global shortcuts, so it's worth trying to override
> anything there, e.g KWin's standard Alt+` shortcut with Atl+È etc. and see
> if it works.

I've just tried.

With French keymap, "Alt+É" as custom shortcut for "Alt+`" ("Walk Through Windows of Current Application) work fine here on Wayland. Doesn't work on X11.

"Alt+`" works for me on Wayland but not on X11. Tried with English US and French keymap (both work on Wayland, both fail on X11).
Comment 15 Andrey 2021-03-26 21:55:48 UTC
Ah, sorry - switching desktop should be Global shortcuts too.
Well, I see why it works now - these symbols seem are actually a Latin script letters, just with diacritics. All these letters must be presented in Qt::Key set: https://doc.qt.io/qt-5/qt.html#Key-enum, so current layout doesn't need to be switched internally for the conversion.

The problem began with non-Latin symbols not represented in Qt::Key set.
So this is actually a different issue than Bug 375518 :)
Thank you for cooperation!

Let's leave it open since you saying it still an issue for X11.
Comment 16 Andrey 2021-03-26 21:58:49 UTC
(In reply to 80p3fy75dc from comment #14)
> "Alt+`" works for me on Wayland but not on X11. Tried with English US and
> French keymap (both work on Wayland, both fail on X11).

Was your US layout configured first in the list, or it doesn't matter?
Comment 17 80p3fy75dc 2021-03-26 22:18:13 UTC
(In reply to Andrey from comment #16)
> (In reply to 80p3fy75dc from comment #14)
> > "Alt+`" works for me on Wayland but not on X11. Tried with English US and
> > French keymap (both work on Wayland, both fail on X11).
> 
> Was your US layout configured first in the list, or it doesn't matter?

I'm getting the same behaviors regardless of the layout order. Tried with French first and US second, then US first and French second.
Comment 18 80p3fy75dc 2021-10-04 09:33:36 UTC
Any update?
Comment 19 Andrey 2021-10-04 11:27:45 UTC
No, sorry. I'm not sure if we have power for proper support X11-specific case here..
Comment 20 Johannes 2022-01-09 18:34:47 UTC
Do you mean that this bug is X11-specific and wouldn't occur in Wayland?
Comment 21 Nate Graham 2022-01-13 03:39:29 UTC
*** Bug 448154 has been marked as a duplicate of this bug. ***
Comment 22 Fabian Vogt 2022-01-23 14:47:18 UTC
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.
Comment 23 Johannes 2022-06-16 08:32:40 UTC
Dear all,
How is it advancing with this bug resolution? Is Fabian Vogt's (previous comment) solution going to be implemented?
Thank you for your feedback!
Comment 24 80p3fy75dc 2022-06-28 17:13:11 UTC
(In reply to Johannes from comment #23)
> Dear all,
> How is it advancing with this bug resolution? Is Fabian Vogt's (previous
> comment) solution going to be implemented?
> Thank you for your feedback!

Still broken on 5.25.2 here. Hopefully it'll be fixed one day.