Rethink global shortcut implementation

[Krzmbrzl]

The problem

As of now Mumble sniffs all keyboard presses made while it is running (no matter whether it has focus or not) in order to be able to provide the global shortcut functionality.

This however requires elevated permissions on Windows and macOS and is therefore a common source of errors and frustration. On Wayland this approach simply does not work at all since Wayland (to my knowledge) does not provide any way to catch the entirety of keyboard input for security reasons.

This makes me think that the current way of doing this is not really future-proof and we should consider getting rid of it.

Potential solution

If we don't want to rely on keyboard sniffing, we have to delegate the job of matching shortcuts to the OS which means that we'll need some sort of API to register our shortcuts with the OS.

These are the respective APIs that I have found for the different OSs:

OS	API	Link
Windows	RegisterHotKey	https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-registerhotkey
macOS	MASShortcut	https://github.com/shpakovski/MASShortcut
macOS	KeyboardShortcuts	https://github.com/sindresorhus/KeyboardShortcuts
X11	XGrabKey	https://stackoverflow.com/questions/4037230/global-hotkey-with-x11-xlib
Wayland	-	-

As far as I can tell there is not shortcuts API for Wayland yet, but I read multiple times that they intend to create one eventually.

There used to be a Carbon API on macOS to register a shortcut but the Carbon API has been deprecated and removed since macOS 10.15 (according to Wikipedia).

There also exists https://github.com/hluk/qxtglobalshortcut that could be used as a basis for a potential implementation.

Problems

The problem of the abovementioned solutions seems to be that they (partly?) only allow to register for a single key plus modifier keys (Ctrl, Alt, etc.) to be registered. Thus you can't register Ctrl+A+B+C. Potentially we could hack ourselves around these limitations but the question would be whether we really need multiple keys to work together.

Another issue that I see is that right now we seem to be able to assign also non-keyboard and Mouse buttons (e.g. from a Joystick, Controller, Headset, you name it) which would not work with these APIs anymore.

Discussion

So the question here really is: Are the drawbacks mentioned here acceptable for the benefits? And are there more drawbacks and/or benefits that I did not think of yet?

Also let me know if you know of any other way of registering a shortcut for any given OS.

/CC @davidebeatrici @Kissaki @ZeroAbility @TerryGeng @sardemff77 (you commented in a very informed way in #3243 (comment))

[Krzmbrzl]

I just found https://github.com/signal11/hidapi which seems to allow getting input from arbitrary HID in a cross-platform way.

[davidebeatrici]

Yes, but you have to deal with the raw USB input data.

[davidebeatrici]

On Windows we can use raw input (I'm already working on an implementation).

On Linux and FreeBSD we can use evdev, which our current implementation already supports but doesn't enable by default.

For X11 we can keep what we already have.

For macOS: we probably have to scrap the current implementation and write a new one that relies on the API used by the libraries you linked.

[davidebeatrici]

Hotkeys can also work when the window is not focused.

The issue is that we cannot be sure that the keys received via Qt events match the ones that we pass to RegisterHotKey(), not to mention we cannot even distinguish between left/right keys (e.g. CTRL and ALT).

[Krzmbrzl]

Hotkeys can also work when the window is not focused.

Afaik that is not true. I mean this is the reason why we even need a system of some kind for global shortcuts, isn't it?

The issue is that we cannot be sure that the keys received via Qt events match the ones that we pass to RegisterHotKey(), not to mention we cannot even distinguish between left/right keys (e.g. CTRL and ALT).

Well the distinction of such keys doesn't seem to important to me. Any why can't we be sure that the keys received via Qt match the ones we pass to the API? I mean we would obviously have to use a function that maps from Qt keycodes to system-specific ones but other than that I don't see an issue 🤔

[davidebeatrici]

Afaik that is not true. I mean this is the reason why we even need a system of some kind for global shortcuts, isn't it?

No, the main reason is much higher flexibility.

Well the distinction of such keys doesn't seem to important to me. Any why can't we be sure that the keys received via Qt match the ones we pass to the API? I mean we would obviously have to use a function that maps from Qt keycodes to system-specific ones but other than that I don't see an issue 🤔

https://github.com/Skycoder42/QHotkey may work.

[Krzmbrzl]

Skycoder42/QHotkey may work.

It definitely looks promising 👀

[davidebeatrici]

I don't like that it polls for key release.