Bug 434949

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 ***

(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.

You're right, my mistake. Sorry about that.

Is this just when setting shortcuts? It's not seen anywhere else?

(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?

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 ***

(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

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.

(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 "À"

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.

(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?

(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.

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.

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.

(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).

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.

(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?

(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.

Any update?

No, sorry. I'm not sure if we have power for proper support X11-specific case here..

Do you mean that this bug is X11-specific and wouldn't occur in Wayland?

*** Bug 448154 has been marked as a duplicate of this bug. ***

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.

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!

(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.

Hi, 

I just tried switching from XMonad to KDE with the tiling extension to try and see if I can replace my WM with a full fledged desktop compatible with Wayland. I tried to set up the key combinations I used for years under XMonad and ran into this same issue.

I'm on a Swiss french keyboard ("fr-ch" variant of "ch" keyboard). Trying to map "Window To Desktop 4" to what would be "Meta+Shift+4", It registers as "Meta+Shift+Ç" (which is a capital "ç", ccedilla is the alternative character on the "4" key, get it with "Shift+4").

I tried to edit it in the ".config/kglobalshortcutsrc", but to no avail. Compared to setting keys in XMonad, where it uses either the letter that is typed when pushing the key or a keycode, it looks a bit inconsistent:
- typing "meta+shift+r", get "Meta+Shift+R". 
   Why capital R ? I'd expect "Meta+Shift+r" or "Meta+R"

- typing "meta+shift+3", get "Meta+*". 
  I'd expect "Meta+Shift+3" to be consistent with the first above, or "Meta+*" consistent with the second. 

- typing "meta+shift+4", get "Meta+Shift+Ç". 
  I'd expect "Meta+Shift+4" or "Meta+ç". I didn't even know how to type that capital ç (Ç) on this keyboard, looks like it's "CapsLock+Shift+4", so the stored shortcut looks like pressing "CapsLock+Meta+Shift+4".


It looks like it stores a weird mix in the config between storing the keycode + modifiers and the keysym (or even the LookupString?). So the shortcut doesn't match what is typed. It would make more sense to me to store the base key and the modifiers. But it seems that all this is handled by Qt, I don't know how this library handles all that.

This happens on Debian Unstable, Plasma 5.25.4, KDE Framework 5.96.0, Qt 5.15.4.

I replaced it with Meta+Alt+<Numbers> for now, but years of muscle memory disagree with this solution :-D
Any news on a fix or any potential workaround by hacking the configs ? 




If it's any help, here are the XEvents from xev when pressing "Meta+Shift+3" and "Meta+Shift+4". I don't understand how it gets to that capital ccedilla "Ç" in the config. 

KeyPress event, serial 40, synthetic NO, window 0x7400001,
    root 0x1c9, subw 0x0, time 3796440, (29,94), root:(1220,816),
    state 0x10, keycode 133 (keysym 0xffeb, Super_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 40, synthetic NO, window 0x7400001,
    root 0x1c9, subw 0x0, time 3796702, (29,94), root:(1220,816),
    state 0x50, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 40, synthetic NO, window 0x7400001,
    root 0x1c9, subw 0x0, time 3796885, (29,94), root:(1220,816),
    state 0x51, keycode 12 (keysym 0x2a, asterisk), same_screen YES,
    XLookupString gives 1 bytes: (2a) "*"
    XmbLookupString gives 1 bytes: (2a) "*"
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x7400001,
    root 0x1c9, subw 0x0, time 3796990, (29,94), root:(1220,816),
    state 0x51, keycode 12 (keysym 0x2a, asterisk), same_screen YES,
    XLookupString gives 1 bytes: (2a) "*"
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x7400001,
    root 0x1c9, subw 0x0, time 3797046, (29,94), root:(1220,816),
    state 0x51, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x7400001,
    root 0x1c9, subw 0x0, time 3797046, (29,94), root:(1220,816),
    state 0x50, keycode 133 (keysym 0xffeb, Super_L), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 40, synthetic NO, window 0x7400001,
    root 0x1c9, subw 0x0, time 3798107, (29,94), root:(1220,816),
    state 0x10, keycode 133 (keysym 0xffeb, Super_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 40, synthetic NO, window 0x7400001,
    root 0x1c9, subw 0x0, time 3798227, (29,94), root:(1220,816),
    state 0x50, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 40, synthetic NO, window 0x7400001,
    root 0x1c9, subw 0x0, time 3798434, (29,94), root:(1220,816),
    state 0x51, keycode 13 (keysym 0xe7, ccedilla), same_screen YES,
    XLookupString gives 2 bytes: (c3 a7) "ç"
    XmbLookupString gives 2 bytes: (c3 a7) "ç"
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x7400001,
    root 0x1c9, subw 0x0, time 3798518, (29,94), root:(1220,816),
    state 0x51, keycode 13 (keysym 0xe7, ccedilla), same_screen YES,
    XLookupString gives 2 bytes: (c3 a7) "ç"
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x7400001,
    root 0x1c9, subw 0x0, time 3798623, (29,94), root:(1220,816),
    state 0x51, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

Addendum: 

Trying to manually change the config file to handle "Meta+Shift+N" with N=3,4,5 with what I would expect:

Window to Desktop 3=Meta+*,,Window to Desktop 3
Window to Desktop 4=Meta+ç,,Window to Desktop 4
Window to Desktop 5=Meta+%,,Window to Desktop 5

Then, log out, log in, and the config file has been changed to 

Window to Desktop 3=Meta+*,,Window to Desktop 3
Window to Desktop 4=Meta+Ç,,Window to Desktop 4
Window to Desktop 5=Meta+%,,Window to Desktop 5

"Meta+Shift+3" and "Meta+Shift+5" work. "Meta+Shift+4" fails...

Likely a dup of bug 415995