Adds a feature that captures the keyboard on the Piano Roll

[IanCaio]

When doing sound design sessions without a MIDI controller, I constantly had to alternate from the VST window to the Piano Roll window so I could press the keyboard keys to play notes and test the sound. I used jack-keyboard once and noticed it has a "Grab Keyboard" feature, that makes the application capture those key presses even when the focus is somewhere else. With that I could tweak the synthesizer with the mouse and quickly test the sound with the keyboard. It sounded like an interesting feature to have on the Piano Roll (and, if people like it, possibly later on instrument widgets).

This PR adds a button on the Piano Roll toolbar that enables and disables "Capture Keyboard". When it's clicked for the first time on a session, a dialog box will show asking for confirmation and explaining the feature (to prevent users from locking the keyboard by accident and not knowing how to unlock it). You can check "Don't ask me again" and it will not ask you for confirmation again on that session. If the user clicks Yes, the keyboard is captured by the piano roll. You can open another window (i.e.: the VST window) using the mouse, since Alt+Tab won't work while the keyboard is captured, and when you press the keys used for playing the notes on the Piano Roll widget, it will receive those and play them. That way you can have quicker sound design sessions, tweaking the synthesizer parameters and quickly playing notes on the keyboard to test them.

To disable the "Capture Keyboard", you can just click again on the button or press ESC. The Piano Roll will then release the keyboard.

---

Note: Tested on Ubuntu 16.04. Needs testing on other operational systems. Some might not allow keyboard capture using Qt's grabKeyboard().

[LmmsBot]

🤖 Hey, I'm @LmmsBot from github.com/lmms/bot and I made downloads for this pull request, click me to make them magically appear! 🎩

Windows

• Windows 32-bit: lmms-1.2.1.682-mingw-win32.exe (build link)
• Windows 64-bit: lmms-1.2.1.682-mingw-win64.exe (build link)
• Windows 32-bit: lmms-1.2.1-msvc2017-win32.exe (build link)
• Windows 64-bit: lmms-1.2.1-msvc2017-win64.exe (build link)
• Windows 32-bit: lmms-1.2.1-msvc2017-win32.exe (build link)
• Windows 64-bit: lmms-1.2.1-msvc2017-win64.exe (build link)

Linux

• Linux (AppImage): lmms-1.2.1.682-linux-x86_64.AppImage (build link)

macOS

• macOS : lmms-1.2.1.682-mac10.13.dmg (build link)

🤖

{"platform_name_to_artifacts": {"Windows": [{"artifact": {"title": {"title": "32-bit", "platform_name": "Windows"}, "link": {"link": "https://6478-15778896-gh.circle-artifacts.com/0/lmms-1.2.1.682-mingw-win32.exe"}}, "build_link": "https://circleci.com/gh/LMMS/lmms/6478?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link"}, {"artifact": {"title": {"title": "64-bit", "platform_name": "Windows"}, "link": {"link": "https://6477-15778896-gh.circle-artifacts.com/0/lmms-1.2.1.682-mingw-win64.exe"}}, "build_link": "https://circleci.com/gh/LMMS/lmms/6477?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link"}, {"artifact": {"title": {"title": "32-bit", "platform_name": "Windows"}, "link": {"link": "https://ci.appveyor.com/api/buildjobs/uk4drffd6vqb153e/artifacts/build/lmms-1.2.1-msvc2017-win32.exe"}}, "build_link": "https://ci.appveyor.com/project/Lukas-W/lmms/builds/32924638"}, {"artifact": {"title": {"title": "64-bit", "platform_name": "Windows"}, "link": {"link": "https://ci.appveyor.com/api/buildjobs/6i6jp2h510i88o85/artifacts/build/lmms-1.2.1-msvc2017-win64.exe"}}, "build_link": "https://ci.appveyor.com/project/Lukas-W/lmms/builds/32924638"}, {"artifact": {"title": {"title": "32-bit", "platform_name": "Windows"}, "link": {"link": "https://ci.appveyor.com/api/buildjobs/3fb2qbc1ou8axdyn/artifacts/build/lmms-1.2.1-msvc2017-win32.exe"}}, "build_link": "https://ci.appveyor.com/project/Lukas-W/lmms/builds/32995074"}, {"artifact": {"title": {"title": "64-bit", "platform_name": "Windows"}, "link": {"link": "https://ci.appveyor.com/api/buildjobs/1kd6bf2gv5omhs4a/artifacts/build/lmms-1.2.1-msvc2017-win64.exe"}}, "build_link": "https://ci.appveyor.com/project/Lukas-W/lmms/builds/32995074"}], "Linux": [{"artifact": {"title": {"title": "(AppImage)", "platform_name": "Linux"}, "link": {"link": "https://6475-15778896-gh.circle-artifacts.com/0/lmms-1.2.1.682-linux-x86_64.AppImage"}}, "build_link": "https://circleci.com/gh/LMMS/lmms/6475?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link"}], "macOS": [{"artifact": {"title": {"title": "", "platform_name": "macOS"}, "link": {"link": "https://6476-15778896-gh.circle-artifacts.com/0/lmms-1.2.1.682-mac10.13.dmg"}}, "build_link": "https://circleci.com/gh/LMMS/lmms/6476?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link"}]}, "commit_sha": "99b5ea06cbf493e766394884132d859b18fa953d"}

[PhysSong]

I tested this on various platforms. It works as expected on Linux + X11, while it works only partially on macOS and Windows. Wayland doesn't allow such a thing.
grabKeyboard() works on a per-session basis on X11 but a per-application basis on macOS and Windows.

[PhysSong]

I just clicked the wrong button.

[PhysSong]

I'm not sure what should we do with this PR. This feature is useful, but the inconsistency can make users confused.

[IanCaio]

I understand if it is decided against merging it. It can be a bit inconsistent between systems. For example, when I wrote it I had Unity as my desktop and it worked as a charm. Right now with GNOME it still works, but the dash can eventually get locked making it a little more annoying to use. You can get around it, just an example of how the behavior might vary. On other OSs it might not even work at all.

A possibility to keep the feature but avoid the confusion it might bring is to make it more of a hidden feature or something, but I'm not sure how that would be done.

Whatever is decided I'm cool with it, just let me know!

[tresf]

I believe Windows allows the direct keyboard access through utilities like DirectInput. macOS is so strict with sandboxing, you'd have to raise a permission dialog to monitor all keyboard input which I expect to be completely doable if Qt plays nicely with the strict security and privacy requirements of macOS. Note, macOS calls this feature "Input Monitoring" and its a built-in OS feature, so it might actually play nicely if implemented properly.

From a UI perspective (I haven't tested this yet, BTW) we may decide to add the red lock icon to the task window so it's even more evident switching to other apps or perhaps use a system notification area or system tray visual to keep reminding people of this. Anything that is detriment to the desktop should be clearly indicated, especially since people could click this on accident and start conspiring about the cause.

For now, I think @PhysSong's feedback can be summarized as follows:

I tested this on various platforms. It works as expected on Linux + X11, while it works only partially on macOS and Windows. Wayland doesn't allow such a thing.

For now, I vote we disable this feature if X11 isn't running (assuming we can safely detect such a thing) although ideally, we'd tell users to just buy a midi keyboard 😆

[IanCaio]

@tresf That's a possibility! I still have to update this PR, I wasn't very confident it would get merged so I haven't merged master in a while, think there are some conflicts.

It will probably have to wait a little while though, I'm spending quite some time in another draft PR I want to finish soon so I can move it to "Ready for review", because it's quite a big one. But once it is done I can come back to this!

[tresf]

@IanCaio just found this too.... https://github.com/hluk/qxtglobalshortcut :D

[IanCaio]

@tresf Will have to take a look, but from a quick glance looks like he isn't using the grabKeyboard method? Interesting, there might be another approach then.

[PhysSong]

I searched for capturing all global key events and found:

• Windows: Use SetWindowsHookEx (https://stackoverflow.com/q/604410)
• macOS: Use event tap, requires accessibility (https://github.com/qt/qtbase/blob/v5.15.0/tests/auto/other/macnativeevents/qnativeevents_mac.cpp)

[IanCaio]

@PhysSong I'll take a better look at those. A quick read on the first though made me wonder something: Those do not actually grab the keyboard right? From what I understood they seem to create a hook so keys can be recognized even when the app is not on focus, but I'm not sure it actually keeps other apps from receiving those key events as well. Even if that's the case, maybe that would allow to make the feature at least partially functional on those OSs. Most synthesizers won't do anything with the keyboard keys that plays notes anyways..

[IanCaio]

Closing this PR due to the fact it's been hanging for a long time and is not guaranteed to work on every OS (I personally can't test it on Windows and MAC, so it's difficult for me to write alternative code for those). I'm not sure many are interested in that feature, but if it happens to be desired it's probably easier for it to be written over in another PR on the fresh codebase.