The kitty shell default shortcut does not work under macOS #4109
Comments
|
This will almost certainly be because cocoa is intercepting You can also add a print around line 514 in cocoa_init.m to see if the |
I don't recall any default cocoa OS window shortcuts related to Ctrl and ESC, except for the system-wide Cmd+Opt+ESC to force quit applications. It is not globally intercepted by the OS or other software.
Event with ESC keycode reaches Thanks, confirmed that the following patch solves the ESC related shortcut issue under macOS, keyup responds normally so no changes are made. diff --git a/glfw/cocoa_init.m b/glfw/cocoa_init.m
index a43aa24e..b9a7fbc0 100644
--- a/glfw/cocoa_init.m
+++ b/glfw/cocoa_init.m
@@ -471,6 +471,19 @@ - (void)render_frame_received:(id)displayIDAsID
return false;
}
+
+static bool
+is_modifiers_esc(NSEvent *event, NSEventModifierFlags modifierFlags) {
+ if (event.keyCode != kVK_Escape) return false;
+ if (
+ (modifierFlags & NSEventModifierFlagControl) != 0 ||
+ (modifierFlags & NSEventModifierFlagShift) != 0 ||
+ (modifierFlags & NSEventModifierFlagOption) != 0 ||
+ (modifierFlags & NSEventModifierFlagCommand) != 0
+ ) return true;
+ return false;
+}
+
GLFWAPI GLFWapplicationshouldhandlereopenfun glfwSetApplicationShouldHandleReopen(GLFWapplicationshouldhandlereopenfun callback) {
GLFWapplicationshouldhandlereopenfun previous = handle_reopen_callback;
handle_reopen_callback = callback;
@@ -511,7 +524,7 @@ int _glfwPlatformInit(void)
NSEvent* (^keydown_block)(NSEvent*) = ^ NSEvent* (NSEvent* event)
{
NSEventModifierFlags modifierFlags = [event modifierFlags] & NSEventModifierFlagDeviceIndependentFlagsMask;
- if (is_ctrl_tab(event, modifierFlags) || is_cmd_period(event, modifierFlags)) {
+ if (is_ctrl_tab(event, modifierFlags) || is_cmd_period(event, modifierFlags) || is_modifiers_esc(event, modifierFlags)) {
// Cocoa swallows Ctrl+Tab to cycle between views
[[NSApp keyWindow].contentView keyDown:event];
}
The modifiers and ESC key events can be seen as normal with |
|
In my testing it is only ctrl or cmd that cause problems, not option or |
|
Yes, there is no need to check the option and shift keys. I have tested the following keys are problematic.
The latest changes have made the above key combinations work properly. I don't think it's necessary to deal with function keys, as they are taken by macOS by default, and this should be turned off by the user in the system preferences. The latest commit causes the default function key global shortcuts for macOS are not working properly.
Since I don't have those default system shortcuts enabled, the function keys were working properly before this commit, at least for me. What worries me most is that I can't find any official macOS dev docs on why Ctrl Cmd with ESC is being intercepted. Hopefully, this will not cause other problems. |
|
On Sun, Oct 10, 2021 at 10:11:48AM -0700, page-down wrote:
I don't think it's necessary to deal with function keys, as they are taken by macOS by default, and this should be turned off by the user in the system preferences. The latest commit causes the default function key global shortcuts for macOS are not working properly.
What doe these keys do and where in preferences can I find them? On my
system ctrl+shift+f6 which is the shortcut for display the kitty config
doesnt work without this change.
Since I don't have those default system shortcuts enabled, the function keys were working properly before this commit, at least for me.
What worries me most is that I can't find any official macOS dev docs on why Ctrl Cmd with ESC is being intercepted. Hopefully, this will not cause other problems.
Yes, I know, Cocoa is alarmingly under documented.
|
System Preferences -> Keyboard -> Shortcuts open /System/Library/PreferencePanes/Keyboard.prefPaneUncheck all unused features and remove all unneeded bindings.
With Accessibility Keyboard enabled, Mac accessibility shortcuts - Apple Support However, it doesn't seem to work on my latest OS. (so Ctrl+Shift+F6 is free to use.) It is possible that the component has been upgraded and the functionality has changed. Also, if you have pressed the macOS default function shortcut that switches the focus, you need to click the mouse in the window, regain the focus, and press the keys again to get the response. In my tests, I also found that pressing the function shortcut key one after another did not work, and I found that the focus was cut off, and it was hard to notice. The issue caused by the current changes can be reproduced by these steps.
|
|
On Sun, Oct 10, 2021 at 03:59:14PM -0700, page-down wrote:
Also, if you have pressed the macOS default function shortcut that switches the focus, you need to click the mouse in the window, regain the focus, and press the keys again to get the response. In my tests, I also found that pressing the function shortcut key one after another did not work, and I found that the focus was cut off, and it was hard to notice.
What shortcut is that? As far as I know cmd+tab is the macOS shortcut to
switch focus between applications and cmd+` to switch focus between
windows of an application. Both work in kitty.
---
The issue caused by the current changes can be reproduced by these steps.
- Enable "Move focus to the menu bar (Ctrl+F2)" on macOS System Preferences.
- Press Ctrl+F2
- Cannot focus on menu bar.
I have fixed this by only overriding ctrl+shift+function key
The proper solution is written in the comment in dc11b76
but is a bit too much work, at least for me as it involves reading a
preference and then reverse engineering bunch of numbers to detect
"important" shortcuts which should be passed through to cocoa.
|
System Preferences -> Keyboard -> Shortcuts -> Keyboard
Since the latest commit no longer handle Ctrl + function keys, the default shortcuts are no longer affected. Confirm that everything above works.
Thank you for the time you invested in solving this issue. I've had enough of Apple things for now, as well. One last problem. // ctrl+esc and cmd+esc
if (ch == 0x1b && (modifierFlags == NSEventModifierFlagCommand || modifierFlags == NSEventModifierFlagControl)) return true;The following key combination was not captured as a result. On the previous commit these keys worked properly.
It is worth noting that the following keys do not need to be handled. Maybe it can't be captured either.
The following are not available and does not matter.
Result of previous commit |
|
In addition to the problem with the ESC shortcut mentioned above, I also found another problem with key events being sent repeatedly. Please note that the previous message mentioned: with previous commit Here is the last change Take Ctrl+Shift+F1 as an example. Subsequent presses of shortcuts seem to be normal. Is this an acceptable result? |
|
Both issues should now be fixed in master. |
|
Thanks, I tested it and so far everything works fine on my system with the keys. |
Describe the bug
The default shortcut for
kitty shelliskitty_mod+escape(Ctrl+Shift+ESC).However, nothing happens when you press this key combination under macOS. It works fine under Linux.
I wonder if there is a special reason why the bound action is not executed.
To Reproduce
Steps to reproduce the behavior:
Ctrl+Shift+ESCunder macOSScreenshots
n/a
Environment details
Additional context
kitty --config=NONE -o "map ctrl+shift+escape kitty_shell window" --debug-inputIt seems that any modifier key with the ESC key suffers from this issue.
The text was updated successfully, but these errors were encountered: