Skip to content
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

Global shortcut overriding cancel and hide shortcut #1217

Closed
nunoh opened this issue Nov 9, 2021 · 1 comment
Closed

Global shortcut overriding cancel and hide shortcut #1217

nunoh opened this issue Nov 9, 2021 · 1 comment
Labels
bug Something isn't working need breakthrough Need a breakthrough idea to move forwards unactionable Further action is not possible due to lack of information or support

Comments

@nunoh
Copy link

nunoh commented Nov 9, 2021

Describe the bug

When AltTab is showing, pressing the shortcut to "Cancel and hide" is triggering a globally set shortcut for other app, not resulting in the expected behavior.

This happens as I have set for show/hide iTerm2 the shortcut (Cmd+Escape), which is getting more "priority" than the "cancel and hide" of AltTab.

For context, in HyperSwitch, the same key combinations result in the expected behavior, that is cancelling and hide of the window manager, rather than triggering the global shortcut.

Steps to reproduce the bug

  1. Invoke AltTab, Cmd + tab, for example
  2. While still pressing Cmd, release tab and press Escape
  3. The AltTab window persists (which shouldn't) and iTerm is made the active window
@nunoh nunoh added the bug Something isn't working label Nov 9, 2021
@lwouis
Copy link
Owner

lwouis commented Nov 9, 2021

This can't be implemented without a trade-off. macOS APIs have limitations. Currently we let users set AltTab shortcuts to pretty much anything (e.g. option+shift is possible).

To enable that, we have a pretty sophisticated implementation which pushes macOS API limitations to its limits. This is something I've spent weeks on. It's using the old, undocumented Carbon APIs, in clever ways to extend what's normally possible.

Once AltTab is open, the other shortcuts are local. They use a completely different implementation. If I remember correctly, the global shortcut carbon APIs don't send the events to AltTab if AltTab is the active app. There are also probably other things involved here, but bottom line is that it wasn't possible to simply have all shortcuts global. I wish it would be that simple.

I don't know how HS allegedly handles it properly, and what they may be sacrificing in terms of functionality in exchange. I know for instance that HS doesn't support shortcuts while Secure Input is enabled. You can test this by pressing HS shortcut while keyboard focus is on a Terminal window, and this is checked:

image

AltTab on the other hand can handle this scenario. That's probably one of the thing we would lose if we moved the implementation to something else to enable the use case in this ticket.

You can see some of my hard work / study back then here: #157 (comment), together with lots of discussion around problems people were facing with the previous implementation (e.g. can't AltTab from login form, 1Password, etc).

Closing this ticket for now as I consider to be technical blockers in the way. If you know a way to move forward and implement it, let me know and I'll re-open this ticket happily 👍

@lwouis lwouis closed this as completed Nov 9, 2021
@lwouis lwouis added need breakthrough Need a breakthrough idea to move forwards unactionable Further action is not possible due to lack of information or support labels Nov 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working need breakthrough Need a breakthrough idea to move forwards unactionable Further action is not possible due to lack of information or support
Projects
None yet
Development

No branches or pull requests

2 participants