-
-
Notifications
You must be signed in to change notification settings - Fork 844
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Shortcuts with the 3-key modifiers Ctrl
+Shift
+ Alt
are not working if KDE's Alt
+ Shift
shortcut is set for changing layout
#3010
Comments
Can you run through the Debugging Keyboard Related Issues section of the docs? That should give us some slightly more focused debug diagnostics, but it also has a suggestion about the IME that you should try. Also, this issue may be relevant:
|
@wez I have already included debug log taken by running wezterm with |
Glad that you found the cause. Sadly, no, wezterm cannot change or intercept system-wide shortcuts like that, or even know if they exist. |
I am thinking of a different approach, not intercepting the shortcuts of the system. As you can see from the debug output, with the keyboard layout changing shortcut being active, WezTerm is still seeing the correct order of key press events. So, I am not sure why WezTerm cannot fire its own action, regardless of what action has been triggered in the mean time by the system (the keyboard layout change in that case). As far as any action triggered by a system-wide key combination that is completed first is not taking the focus from WezTerm's window, WezTerm can still continue receiving the key press events needed to complete the combination that triggers its own action. |
keyboard processing is complicated; just because a key may be physically marked as While it may be possible for wezterm to assume a use, it would be counter to the behavior of the system and be a source of more bug reports. I'm not going to add logic to wezterm to treat the keys in that way. However, if you feel strongly that you want it to work that way, and don't want to configure your system to remove the conflicting key assignment, you may wish to look at using Key Tables to try to define that mapping for yourself. |
Ctrl
+Shift
+ Alt
are not workingCtrl
+Shift
+ Alt
are not working if KDE's Alt
+ Shift
shortcut is set for changing layout
I have changed the title of this issue to represent the actual problem I was facing. I am not sure if the keyboard layout is relevant and I will explain why. I have tested this by setting just two layout options, English and English (aka the same layout twice), so that the system shortcut does not actually change the layout, and the problem still exists. The problem exists even with just one layout option (English) configured, but with the Alt + Shift shortcut still active (and having no apparent effect). The only way to make Wezterm's shortcuts with CTRL + SHIFT + ALT modifiers work is to set KDE's shortcut for changing the keyboard layout to something different than Alt + Shift. So, what I have come to, and I am satisfied with that, is to set the KDE's keyboard layout changing shortcut to LeftAlt + LeftShift. That way I can use the RightCtrl + RightShift + RightAlt combination for WezTerm's actions (split pane, etc.) to work. This combination will not work though if the keyboard layout has been changed to Greek layout! Surely, I can live with it, but it is quite strange... I set the keyboard layout changing shortcut to Alt + Shift, WezTerm's shortcuts become dead, but the keyboard layout is not relevant. I set the shortcut to LeftAlt + LeftShift, WezTerm's shortcuts work with English layout but not with Greek layout, making in that case the keyboard layout relevant! Go figure! Another question I have, and this has nothing to do with WezTerm, is why my system (KDE) is triggering the keyboard layout changing action even if I start pressing and keeping down the Ctrl key first, then Shift, then Alt. I mean, if the configured shortcut is just Alt+Shift (or LeftAlt + LeftShift), without Ctrl, why does KDE trigger the action while I am pressing Ctrl first? Does it make sense? |
All of the things you've described are happening at a layer above wezterm, in your windowing environment. I'm going to close this out as it is out of the scope of this project. |
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
What Operating System(s) are you seeing this problem on?
Linux X11
Which Wayland compositor or X11 Window manager(s) are you using?
KWin
WezTerm version
20221119-145034-49b9839f
Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?
No, and I'll explain why below
Describe the bug
Using the mentioned version of WezTerm from the latest archlinux package, I cannot trigger an action via a shortcut that involves the pressing of
Ctrl
+Shift
+Alt
modifiers.For example,
Ctrl
+Shift
+Alt
+"
, which is the default combination to trigger theSplitVertical
action in order to split the active pane vertically, does not work. As you can see in the debug output I am posting below, it seems that theAlt
key has not been added to the modifiers combination when theKeyEvent
event for the"
key press is generated. An interesting observation I can make in the debug log is the fact that the key press ofAlt
only produces aRawKeyEvent
event, in contrast with the other two key presses ofCtrl
andShift
before, which have produced each both aRawKeyEvent
and aKeyEvent
event.However, If I press some other combination (not mapped to an action), e.g.
Ctrl
+Alt
+Super
+m
, I can see in the "KeyEvent" event of them
key press that all the modifiers include all pressed modifier keys (Ctrl
+Alt
+Super
). In that case, the key press ofSuper
has triggered both aRawKeyEvent
and aKeyEvent
event.To Reproduce
No response
Configuration
return {
scrollback_lines = 20000,
ssh_domains = {
{
name = 'somehost',
remote_address = 'someaddress',
username = 'someusername',
},
},
}
Expected Behavior
No response
Logs
Anything else?
No response
The text was updated successfully, but these errors were encountered: