Hacker News Reader

Comment by mirthflat83 | Hacker News Reader

I like how they named it. If you can get permission for systemwide keystrokes it is also obviously able to see what you’re typing in other apps. More straightforward for those who are not tech oriented.

View on HN

Sounds like a bad API. There should be a way to register shortcuts and macros without giving keystroke information to the app.

Doesn't linux work like this? Where certain input starts at the top (kernel), and then goes to the first program that "listens" for a certain key/combo?

So you could have a program only listen/capture certain keys?

XWin app can listen to all keystrokes in system. This was fixed in Wayland.

Two different questions. You're talking about whether the app must get the user's approval. The question here (in this part of the thread) is whether the app must subscribe to all events and filter them itself or if it can instead subscribe to a filtered version of events.

I know that an Xapp can listen to everything, but I was thinking that it can listen to only some keys/combos.

How would you write an application that uses global shortcuts in Wayland?

Probably through a series of incompatible and as-yet-unimplemented APIs for each desktop environment and window manager you want to support.

You wouldn't, because Wayland is not ready for consumption by people that use their computer with expectations of full functionality. The obvious things for most people (shortcuts being one of them) do not yet work in it.

"fixed".

Especially given Apple apps seem to be able to register keyboard shortcuts in the system preferences and let you change them...

That works through the menu system, so any app that uses the standard menubar can have shortcuts reassigned. It works well, but it comes with the downside that the shortcuts are not global.

If we're at API design, I'd like an even more abstract one: Let the app register intents with associated title, description, icon and suggestion for a keyboard shortcut and let the OS manage how the intent is invoked.

Carbon hotkeys are how you register for a single keystroke. Event taps give you everything. This sounds more like the latter.

Only because MacOS doesn't provide a more specific shortcut functionality. It should let an app register the specific keystrokes to get notified by, and doesn't need to notify which app was foreground when the shortcut was invoked.

Since the proper API isn't available, the principle of least privilege suggests that abusing a high-privilege, easily abused feature in an unorthodox manner to work around that problem might be a bad idea. Maybe MacOS shouldn't have this "systemwide shortcut" feature until it provides the necessary functionality. Currently that feature appears to be incompatible with the platform's security model; don't undermine that model just to make a hotkey feature work.

My guess is this API predates the introduction of these new security approvals. Some quick googling revealed that several developers are not even clear why their app causes the new macOS to ask the user for this approval.

I agree it's better not to have features that don't mesh with the security model, but when you're tightening down the security on an existing design, you may have to deal with awkward transitions. Even if they introduced a replacement API that fits with their security model better, a bunch of apps out there would have to be ported to use it, so they're going to need to maintain backward compatibility for a long while.

It would also be helpful in letting users figure out conflicting shortcuts.

But why would that permission be needed at all for this use case? Is there not a simple "allow us to create a keyboard shortcut" permission?

Reply on news.ycombinator.com