search

xkbcommon / libxkbcommon

keymap handling library for toolkits and window systems
https://xkbcommon.org
Other
279 stars 124 forks source link

keyboard layout change to CTRL-Shift/ALT-Shift breaks other shortcuts starting with CTRL-Shift/ALT-Shift #420

Open ezhan opened 9 months ago

ezhan commented 9 months ago

Trying to move from Windows to Linux & KDE (Gnome is affected as well). Found a ground braking misbehavior, making the move for me impossible. I used to change layouts with CTRL-Shift on Windows for 30 years as many other users.

Many multi language users suffers from this issue.

STEPS TO REPRODUCE

  1. Add keyboard layouts: English, Estonian, Russian (it should work with only two added languages, but I have three of them)
  2. Set keyboard language switcher to CTRL-Shift

Try to: a) in Firefox close a tab and reopen it with CTRL-Shift-T shortcut b) in Konsole try to copy a text with CTRL-Shift-C shortcut c) any CTRL-Shift-X combinations in any program that supports any of such shortcuts

OBSERVED RESULT a) opens a new tab b) sends CTRL-C to terminate a command c) any CTRL-Shift-X will not work

EXPECTED RESULT a) reopens a closed tab b) copies selected text c) shortcuts works as designed by the program

THE PROBLEM ROOT Pressing CTRL-Shift immediately changes the language, so the pressed letter does not do anything. Why? Of XBD standard. XBM triggers on pressing of a button, not on a release.

More information: A 20 years old bug for X11: https://bugs.freedesktop.org/show_bug.cgi?id=865 KDE discussion: https://bugs.kde.org/show_bug.cgi?id=383113

There is a patched X11 available, but since all moves to Wayland, it is not an option anymore: https://www.shellhacks.com/ctrl-shift-key-not-working-ubuntu-linux-mint/

EDIT 2024-06-17:

Now I have the exact guide to workaround this problem in KDE 6.1 and newer (release is scheduled for next week, 18.06.2024).

  1. Open Settings -> Keyboard -> Layouts
  2. Delete the assigned MAIN shortcut (CTRL-Shift or ALT-Shift), you may have to uncheck it in "Key Bindings" and apply.
  3. Assign Ctrl+Shift as ALTERNATIVE shortcut and apply.

Now it works as desired!

ezhan commented 9 months ago

Not only CTRL-Shift+ are affected, ALT-Shift+ as well, when ALT-Shift is set to changing layout.

ezhan commented 9 months ago

Can add, that CTRL-Shift-cursor key selection does not work as well - selection does not happens.

ezhan commented 9 months ago

  1. Thank you for your work! I will install it on our warehouse PC with Ubuntu & Xorg.

  2. I personally decided to go with Fedora, as it is a semi-rolling updates distribution. Ubuntu, even not LTS still has no KDE 5.27.8, when 5.27.10 is available. But this is not about this bug.

  3. Your patch is for xorg, but now all are going to Wayland (Fedora already defaults to it)...

diminDDL commented 9 months ago

+1 on this,one, the patch works well, but is not an option for wayland and or non ubuntu users. This is clearly a bug that needs to be addressed at the source and not be patched by third parties.

shattl commented 8 months ago

+1 on this, really need to fix not by end-users

ezhan commented 8 months ago

Since here is no activity of the developers/maintainers, I have sent an e-mail. Hope it will help get some love here.

If someone knows an other way to get attention please do it.

TO: xorg-devel@lists.x.org, wayland-devel@lists.freedesktop.org, ran@unusedvar.com SUBJ: issue 420 - keyboard layout change to CTRL-Shift/ALT-Shift brakes other shortcuts starting with CTRL-Shift/ALT-Shift

Hello.

Sorry to bother directly, but this is a deal breaker for many multi layout users and the bug has no developer/maintainer activity.

100% of Windows users defaults to CTRL- or ATL-Shift for changing keyboard layout.

In Linux there is a huge problem with that combinations, since it breaks all CTRL- or ATL-Shift+ shortcuts in programs. Please read explanation here: https://github.com/xkbcommon/libxkbcommon/issues/420

KDE/Gnome refused to deal with it directly, since it is managed by XKB and should be fixed here.

Tnx.

wismill commented 7 months ago

Duplicate of #92. As written in various places, this is not a bug per se, but rather a limitation of the XKB protocol. I recognize it is equally annoying for the end user. We are aware of it, but you should understand that this is tricky to fix while maintaining perfect backward compatibility, on top of that with scarce manpower.

There are temporary solutions:

Please:

Thank you for your understanding.

ezhan commented 7 months ago

  1. I want to contribute 100 € for the fix (to person or project).

  2. We really have to start by something. For me sounds reasonable the proposal of making an alternative version and let all wanting this fixed to install it, test it out and report if any change to "do on release" behavior breaks backward compatibility or makes any other issues.

Nixellion commented 5 months ago

I would also be willing to donate money for this fix if someone makes a fund or just links a donation link. This is honestly quite a dumb small annoying issue, but it's one of many similar small quirks that Linux has which make it feel less polished and buggy for majority of Windows\MacOS users. It's also astonishing that this has been an issue for decade(s) without a fix.

sergio-nsk commented 5 months ago

@wismill

to fix while maintaining perfect backward compatibility

What a backward compatibility are you talking about? Nobody uses the Ctrl+Shift and Alt+Shift as complete combinations because they break the continued combinations Ctrl+Shift+\ and Alt+Shift+\. The Ctrl+Shift and Alt+Shift should be considered complete on key up, not key down.

koread commented 5 months ago

Thanks to the author for opening the discussion. I also join the request to pay attention to this situation.

On Windows, I have been using the Ctrl+Shift combination to change layouts for decades. In Linux (no matter what distribution) I choose the same combination, but then some combinations in applications stop working, for example: Ctrl+Shift+T in Firefox (cancel closing a tab) Ctrl+Shift+M (and others) in Telegram (text formatting)

I tried other combinations to change the layout (including Capslock), but could not get used to it. I have to give up shortcuts in applications and spend time calling up the context menu.

Please someone find a solution that works for both parties. I'm not asking you to change the behavior globally, just the ability to change it for an ordinary user (for example, by editing configuration files)

ezhan commented 4 months ago

@xkbcommon, @wismill do you have any idea how we can go further? Where or whom to write, bet, ask?

dmitry-azaraev commented 4 months ago

The Ctrl+Shift and Alt+Shift should be considered complete on key up, not key down.

I guess it is already clear, but just want explicitly state: shortcuts on modifier keys like Alt+Shift should be considered complete on key up AND in absense any other keystrokes in-between. E.g. pressing Alt+Shift+Something might trigger something in apps, but should never switch layout, not on keydown nor on keyup. This logic is so natural... Is similar to mouse click on button requires mousedown over button, and mouse up over same button, no matter how long you press and how long you move out and in back.

treapster commented 4 months ago

Duplicate of #92. As written in various places, this is not a bug per se, but rather a limitation of the XKB protocol. I recognize it is equally annoying for the end user. We are aware of it, but you should understand that this is tricky to fix while maintaining perfect backward compatibility, on top of that with scarce manpower.

It is not a limitation, it is a buggy specification. But i don't understand why it is used as an excuse not to fix it. Why do you want to maintain compatibility with something that was broken from the start, annoys everyone and no one really likes? There is 20 year old thread of people complaining about it over 200+ comments, not a single one of them said "wait but i rely on current behavior!". Every user coming from Windows or macOS will be bitten by this bug, why do you suppose that fixing it will be more harmful than letting it ruin everyone's workflow? It doesn't make sense for me, as well as for other people affected, and there are hundreds of them(check the like counter on the issue).

ezhan commented 4 months ago

The main problem is no one is working on this, even to make a version users can install and test out... :(

treapster commented 4 months ago

The lack of manpower is less of an issue if maintainers are willing to accept a patch

wismill commented 4 months ago

Locking, because the comments are not constructive. Please read my comment on this topic.

Please do not contribute to make maintaining this library a more thankless job than it is already.

wismill commented 4 months ago

It seems my comment on compatibility was misunderstood. I meant that the XKB protocol is what it is – for better or worse – and hacking against the protocol might introduce very tricky bugs, breaking compatibility of other features.

I did experiment a more general solution, but it is not clear how to make it backward-compatible. So… progress is slooow.

The lack of manpower is less of an issue if maintainers are willing to accept a patch

@treapster we do accept patches. Except none has been sent for this issue.