Qtox: Feature request: support global hotkeys, including global push to talk

[anthonybilinski]

This issue is a continuation from my previous PR https://github.com/qTox/qTox/pull/4925 which got carried away, changed topics a couple times, and ended up not being related to the original issue of hotkey configuration.

The want for global hotkeys was also brought up in the comments of https://github.com/qTox/qTox/issues/903

Our current push to talk implementation is only supported if the qTox window has focus. This is not very useful for any gaming use, where push to talk is often used and the game will always have focus.

Qt doesn't have a built in global hotkey solution, since it only captures key presses when it has focus. I've explored pulling in external libraries to handle the cross platform hotkey handling for us, instead of rolling our own which would both be a lot of work and seems like we must be re-doing work that has been done elsewhere.
Some candidates I've looked at:

1. Qxt Library: Large extension library that is no longer maintained. Not appealing.
2. UGlobalHotkey: Doesn't offer key-up events so can't be used for hold to talk, and also consumes key presses interfering with typing.
3. Mumble's implementation: 3-clause BSD which is compatible with GPL. Has OS-specific implementations for win, macx and x11, and works well enough for them, offering key down and key up. I've done research on the license compatibility, and it looks like we must keep their BSD license disclaimers, add their BSD license into our source and have it available on releases, can add our own GPL, make our changes under GPL, our produced binaries would all still be GPL. Mumble would not be able to upstream any changes we made under GPL. Citation for strategy I'm looking at is under 2.2 of https://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html

I talked briefly to some Mumble community and devs on IRC to double check that they agree it's within their license and also that they're ok with the idea of it. After a few hours in chat, there were a few comments agreeing it would be legal, and no comments disagreeing or expressing disapproval of the idea. This is no way releases their copyright or has any real legal meaning. Attached is a brief IRC log: mumble-irc-log.txt

There was also no disagreement from qTox members in the linked PR when asked about introducing some 3-clause BSD code.

I'm currently working on integrating Mumble's GlobalHotkey code and will PR shortly.

[anthonybilinski]

Sorry for the slow response, I got distracted and busy and haven't worked on this in a couple weeks :(

@tox-user has been working on the UI of setting key bindings and saving / restoring them as well as selecting the audio control method (continuous, threshold, PTT). I've got the the hotkey engine working well on *nix with pretty heavy changes from what mumble had to strip it down to a the minimum API of setting a list of keys and connecting to signals of the constructed object. Manually connecting the PTT engine to audio mute works well in testing.
Left to do:

• [ ] I need to clean up my PTT engine changes, still some unclean changes
• [ ] I need to do equivalent changes for the windows and osx implementations, shouldn't be too much work
• [ ] Might be some finishing up of UI, I'm unsure, would be handled by tox-user
• [ ] There's currently nothing in progress (or any concrete plans) of how to connect the settings with the shortcut engine. This would be a good thing to work on if you want since it's not already half done. Would need to take in the type of audio selected (continuous, threshold, PTT) and optionally the PTT list of keys, and register the list of keys with the engine, then handler the logic of muting/unmuting all chats on PTT if PTT is selected or on threshold if threshold is selected (this might already be done for free, not sure). This could be done by either ignoring the signal from the PTT shortcut trigger or by unregistered the shortcut. It might be easier to do this after the shortcut engine and UI are more finished so you know what you're working with.

There is a PR: https://github.com/qTox/qTox/pull/4936
I'll update this PR soon™ including pulling in @tox-user's UI changes.

[HoraceBianchon]

What about qt libqxt library? I know it is now not maintained and very big. But I think I can take only global hotkey part and use it.
I will try implement simple global hotkey in my repository to see how it works.

[data-man]

There is very good QHotkey (BSD-3-Clause).

[ghost]

Soon? :)

It would be great to see push to talk implemented, it would help me drop my Mumble server altogether. Have you guys figured out the donation stuff yet? I would love to send a little bit of coffee if it provides some extra motivation :).

[tox-user]

@MAL315 for donations we would need a non-profit organisation (there was a discussion about it here: https://github.com/TokTok/c-toxcore/issues/738). Currently the only way is to contact a developer directly.

[ghost]

Who are all the devs that are working on this? What's the best way to contact them?

[tox-user]

It was @anthonybilinski and me. You can contact me on Tox. I only worked on the UI part of setting shortcuts in settings though. It was @anthonybilinski who was doing all the work of integrating Mumble's push to talk code into qTox.

[anthonybilinski]

I just tried QHotkey and qxtglobalshortcut which is pretty much what Horace described, but both consume the key pressed as well as all other keys pressed afterwards for about 300ms. This seems pretty unusable to me and would cause lots of strange behaviour for users.

My original goal was to save hotkeys in QKeys, but there's no supported way to convert between QKeys and symkeys. qxtglobalshortcut uses an internal table from Qt but this seems undesirable from a maintenance point of view and like we'll always be missing some keys on some input devices, plus reduces usable keys since Qt doesn't distinguish between all physical keys like scancodes or symcodes do (i.e. numpad numbers). I think a better option is to just save shortcuts in symkeys generated in the QKeyEvent's nativeVirtualKey() by the user setting the key the first time. The shortcuts can then be saved per-platform in the settings file and some UI notification could be used if a user transports a profile across systems that they need to re-set their shortcuts.

This also has the benefit of not tying shortcut implementation to Qt, but I can't find a nice cross-platform C or C++ library that just takes in a list of symcodes and calls a function pointer or lambda when they're hit. That's still compatible with most of the work I've done with mumble's implementation, so I'll move in that direction and hopefully split it off into its own library.

[Diadlo]

@anthonybilinski Maybe you will be interested in keepassxc global hotkeys implementation: https://github.com/keepassxreboot/keepassxc/tree/develop/src/autotype

[anthonybilinski]

Just tried keepassxc (and keepassx) and they both consume the global shortcut as well (i.e. bind to shift+C, can no longer type "C-api".

I've started work into a C-api standalone cross platform library that registers a callback with a list of keys, without consuming any keys pressed using parts of the my existing port of Mumble. I'll keep working on this, but if people know of more open source global hotkey implementations I'll happily take a look so that I'm not duplicating work.

[ghost]

It's not possible to use thr exact same implementation as mumble? You can hold the key down in mumble as long as you want and it works fine. The wizard asks you to select the key bind you want to use.

[anthonybilinski]

I'm basically porting the mumble implementation which works well, while stripping out global mumble state, Qt utility functions, and Qt graphical components which are part of theirs. Qt utility components are ok for us, but I don't want to add a graphics library to a hotkey library. I also have problems testing OSX, when I was trying to get a VM running I kept having boot problems, but I'll push platform-by-platform as I add support, starting with posix then windows.

[tox-user]

Sounds like you are making it even more work for yourself than it was previously. I think it would be better to just focus on getting it to work well and worry about removing Qt stuff and making it a separate library later.