Have a way to skip sending Keyboard shortcut to apps that use float windows (like Raycast/Alfred)

[bjrmatos]

example use case:

Chrome has a keyboard shortcut (⇧⌘A) to open a search tabs feature, i don't like that keyboard shortcut, instead, i want to use ⌘P, so i have created this workflow:

this works as expected, however, I've noticed that this breaks the keyboard shortcuts in Raycast if they have some action attached to ⌘P

i think the problem is that Cowboy still thinks that chrome is active and at the front, so when i press ⌘P with Raycast launched it sends ⇧⌘A to Raycast (which is not what i want), i want that Raycast receives just the original ⌘P.
just for the sake of testing i have tried enabling the "Passthrough" and it makes it work with Raycast, however now when doing the keyboard shortcut with just Chrome it trigger both the Search Tabs and a Printing Dialog, so likely the "Passthrough" is not good solution for this case.

i have tried other apps trying to fix this specific problem (Keyboard Maestro, BetterTouchTool) but they fail to handle it, it will be a major killer feature for me if you somehow manage to do it.

this is a video that shows the case: https://share.cleanshot.com/lkkCpgYv

thanks!

[zenangst]

@bjrmatos

Interesting, I see the problem and know why it happens.
Keyboard Cowboy doesn't care about which apps has focus, it checks which is front most. Raycast never becomes front most, unless the preference is actually opened.

There is workaround that could be applied here, but it would involve using the Accessibility API, which is known to be slow.

We could consider enabling an additional flag on the group, that it should only be applied if the currently focused element belongs to the application attached in the group rules. That might work, it would be an opt-in feature in that case.

I'll have to do some additional investigation to figure out if this solution is viable.

[zenangst]

And again, thanks for bringing this to my attention, I've never stumbled upon this issue before.

As a workaround, you should be able to rebind the key in Google Chrome by using the System Settings way of rebinding it (if the shortcut is located in the menu for the app). Have you tried that already?

[bjrmatos]

We could consider enabling an additional flag on the group, that it should only be applied if the currently focused element belongs to the application attached in the group rules. That might work, it would be an opt-in feature in that case.

I'll have to do some additional investigation to figure out if this solution is viable.

oh yes, excellent, i will keep an eye for any updates, thank you!

As a workaround, you should be able to rebind the key in Google Chrome by using the System Settings way of rebinding it (if the shortcut is located in the menu for the app). Have you tried that already?

hmm no, i have not tried it, it is a good idea, i will check. it may be great for this case however i have plans for other shortcuts that are not in the menu, i just don't want to have conflicts with Raycast shortcuts :)

thanks again for looking into this

[zenangst]

Thought a little more about this problem and it is not as easy as I thought it would be.
Mainly because we don't have a subscription mechanism in place for when the currently focused element changes. Will have to do a little more tinkering before we can come up with a viable solution.