Projectreunion: Global shortcuts for UWP apps

[MarcAnt01]

Snip and Sketch uses Win + Shift + S and is a UWP app, but it does that Windows side. I'd like to use the same capability for my UWP app.

Proposal: [Global shortcuts for UWP apps]

Summary

Shortcuts like Win + Shift + Letter or just Win + Letter could be used by UWP apps.

Rationale

• I shouldn't be forced to use Desktop Bridge or a Win32 application just for this side feature

Scope

| Capability | Priority |
| :---------- | :------- |
| This proposal will allow developers to accomplish W | Must |

Important Notes

Api proposal

Open Questions

[Jaiganeshkumaran]

First of all apps must declare the shortcut in the manifest not by registering at runtime. Also apps must not use the Windows key. Instead the should use any other key. Users must be able to disable global shortcuts for all UWP apps from Windows Settings.

[ShankarBUS]

@Jaiganeshkumaran,

Windows settings? That will require change in the OS! And won't be backward compatible.

IMO, the app must be able to register hotkeys at runtime, so that the Devs can provide a way for the users to customise them.

Windows settings could be used to just disable all global shortcuts for a particular app.

Imagine an app like PowerToys using Windows settings to register/modify global hotkeys, no one would like going to settings just for this.

[Jaiganeshkumaran]

@ShankarBUS For Win32 apps that's fine but the great thing about UWP is that it makes Windows better. Apps shouldn't just be able to add it at runtime because the user will not know. This is one thing that's good with UWP apps and you shouldn't just make it unsecure like Win32. Backward compatibly isn't needed for this since it's not crucial.

[maxkatz6]

@ShankarBUS
I believe safe way to implement this feature will require changes in the OS in any way.
Even if application will ask user to confirm specific keys chosen in runtime, it will not work without changes in the OS (or it could be managed by WinUI layer, that isn't really safe).
In worst case app can listen for any keyboard signals.

PowerToys can require special restricted capability to handle any shortcuts. (again, OS changes)

[ShankarBUS]

@Jaiganeshkumaran, @maxkatz6

So you two believe that using the settings will be the safest way for global shortcuts.

But if these changes are made in say next Windows release, they won't be available on older windows versions. Which makes the shortcuts useless on older versions.

I too think that'll be the safest and organized way (and will be similar to notifications, privacy, devices & sensors access, storage access, file integration & etc). But it won't available on older versions anyways.

At least for win32 apps, it should be possible like what I said.

[Jaiganeshkumaran]

@ShankarBUS No it's not needed. Global shortcuts aren't really required. Microsoft can make it a new feature in the next update.

[MarcAnt01]

First of all apps must declare the shortcut in the manifest not by registering and runtime. Also apps must not use the Windows key. Instead the should use any other key. Users must be able to disable global shortcuts for all UWP apps from Windows Settings.

Win32 apps can use it, so I think it's a good choice to reach feature parity, otherwise devs will continue to prefer to use Win32 like it's been happening for years just because uwp is too limited

[Jaiganeshkumaran]

@MarcAnt01 That doesn't mean UWP should become just like Win32. Everything should be done with user security in mind and that's why UWP exists.

[MarcAnt01]

What's the risk of using a global shortcut?
I don't wanna flame, but the restriction for "privacy" are moving away devs from uwp, when building a uwp app (main target now is Desktop), having to deal constantly with restrictions is discouraging. If MS doesn't at least try to make the platform closer to Win32, the situation isn't going to change any time soon. It isn't 2015 any longer when restrictions could be justified by the multiplatform nature of the framework.

[Jaiganeshkumaran]

@MarcAnt01 Privacy is really important. Global shortcut has a lot of potentials for misuse so it should be handled with care. Developers should focus on privacy to be future proof.

[MarcAnt01]

@Jaiganeshkumaran you still haven't explained the potential risks

[Jaiganeshkumaran]

@MarcAnt01 First apps can replace built-in key shortcuts which shouldn't be allowed other than that it's pretty safe but the user should be aware of it and should be able to disable. You might give an option to disable shortcuts but other might not so I think it should be in the Settings app which requires a new update.

[MarcAnt01]

That's a good point, but:

• UWP apps are going to be distributing through the store, since deploying them is a horrible choice (so Microsoft can check their usage);
• I think built-in shortcuts shouldn't be replaced, there should be a list of available ones

[Jaiganeshkumaran]

@MarcAnt01 That's not for sure. Some UWP apps are distributed outside because they have money for a certificate. For built-in shortcuts the API should ignore the request.

[MarcAnt01]

Only big companies can afford the prices, in fact just Adobe does that, so it isn't a problem in my opinion

[stevewri]

I want to make sure I understand the ask. Windows allows apps, once they've been launched, to programmatically declare shortcuts or accelerators that invoke specific application actions, but that's different. The ask here is for apps to register (via manifest) something that will cause the shell to launch that app, correct?

And then, per the discussion, consider issues such as:
1) Should an app be able to "take over" a system default global shortcut, w/ or w/o user permission? Security & privacy issues
2) Should an app be able to "take over" another app's global shortcut, w/ or w/o user permission? Similar issues
3) Deprecate legacy mechanisms Win32 apps use to achieve similar results?

[Jaiganeshkumaran]

@stevewri Yes apps shouldn't register after they have been launched. Instead they should add the them to the manifest and when the user presses the hotkey the shell should launch that app with the arguments given in the manifest.

1. Should an app be able to "take over" a system default global shortcut, w/ or w/o user permission? Never unless that app replaces the shell like a custom shell application.
2. Should an app be able to "take over" another app's global shortcut, w/ or w/o user permission? Since it's declared in the manifest, Windows should show a dialog to select the app that the user wants
3. Deprecate legacy mechanisms Win32 apps use to achieve similar results? Should be done

[MarcAnt01]

@stevenbrix

1. No the app shouldn't replace system shortcuts;
2. Let the user select the preferred shortcut;
3. Yeah, I think the behavior should be made consistent.

[Jaiganeshkumaran]

Anything that starts with the Windows key should not be allowed. Other reserved shortcuts like Alt+Tab shouldn't be replaced.

[MarcAnt01]

I don't agree on this point, Windows key shortcuts should be made available also for third-party apps

[Jaiganeshkumaran]

@MarcAnt01 Apps can have Windows key shortcuts inside their app but not global. Only Windows stuff should use a Windows key shortcut.

[xyzzer]

RegisterHotKey (and UnregisterHotKey) is the Win32 hot key API. I'm not sure if it's available to Store apps, but I think it might be.

One problem with it though is that I think it requires a running process, so while Win32 apps could run hidden, perhaps with a tray icon, for UWAs it would be a bit problematic, especially that they can be suspended any time. Having a way to register a hot key in the system for current user session to activate the app with information about the hot key used would be quite powerful.

IIRC, the Win32 API fails if the hot key combo had already been registered leading to race condition problems when multiple apps try to use the same hot key. A hot key owner picker similar to protocol handler or file type handler pickers could be used by default to solve a problem with an app trying to register a hot key that had already been registered before. It could possibly even be used with the old Win32 API. It would be helpful if an app could also detect if one or more of the hot keys it tries to register are already taken without triggering the picker in order to show some UI to the user to disable or change the hot keys that are already taken by other apps before registering them.

Perhaps the OS could provide an API to register multiple hot keys and provide shared UI to change the combinations, pick which app owns which hot key, what to override it with etc. An app would have to provide a description of each hot key and then be notified whether the suggested combination was overridden or turned off in the picker.

There's a lot that could be done, but it would probably all need to be done in the OS.

[Jaiganeshkumaran]

@xyzzer Since UWP apps can be suspended anytime, it could be brokered and Windows could resume the app when the hokey is activated. However normally since foreground apps are suspended when you switch to another app, it's not a good idea to automatically switch back and resume the minimized suspended app. It could be handled by a background task instead

[zakius]

Global hotkeys, in one form or another, are a necessity: currently I'm using AHK to toggle windows of 3 persistent Store installed apps (that aren't actually UWP and all of them have ability to do it themselves but could make use of the new API)

While it may be a good idea to expose all UWP ones in central places to avoid collisions (like newer variants of WebExtensions API do with Commands) it still will interfere with classic apps and it can't be avoided and I believe we have to just accept it this way. Besides that that central hotkey config would allow us to personalize built in Windows hotkeys + handle some new ones (like the before mentioned window toggle that probably should be handled by window manager itself, not apps)

And out of curiosity, how are shortcut hotkeys exactly handled internally? Probably Explorer registers them somehow so these would end up on the list too so only keyboard hooks would end up missing