Introduce keyboard scroll flag in Virtual Console

[Pac72]

This is the second try to fix #1443, after a first attempt with pull request #1584 that covered only VCButtons.
The approach on this change is completely different: introduce a flag to choose whether or not to use arrow and PgUp/PgDown keys to scroll Virtual Console.
When the flag is disabled, all the keys are available as key combinations on the controls.

Side changes:

• in assignhotkey.ui the former QLineEdit has been replaced by a QLabel to allow capture of (almost) all the keys (the QLineEdit consumes at least backspace, delete, home, end, left and right cursor keys)
• the CTRL+key combinations are completely blocked

Closes #1443

[coveralls]

coverage: 32.056% (+0.02%) from 32.034%
when pulling e0912e5 on Pac72:issue-1443-vc-settings
into c1f5846 on mcallegari:master.

[Pac72]

Hi @qfulmina , did you hava a chance to try this change?

[yestalgia]

We don't need a flag. I think it's better to use the scroll lock feature built into nearly every keyboard.

https://www.youtube.com/watch?v=NJ0U8RmW-oE

[Pac72]

So, at last, after more than 40 years, we finally found a use for the scroll lock key! :-D

To be honest, I don't really like basing the scrolling behaviour only on the scroll lock key.
Nobody knows/uses it, a lot of keyboards do not have it anymore, on Macs you seem to have to press "Fn" + "Shift" + "F12", and even on my MX Keys S you need to press "Fn" + something (I didn't even know it was supported...).
Most importantly, using a configuration allows for selection at design time, whereas pressing a button would only be useful at show time and might not be intuitive for everyone (in the video, around 4:49, Dave tells that similar concerns may have led to choose F7 instead of scroll lock to toggle caret browsing on web browsers).
Side note: on a stock Ubuntu 24.04 (my main dev environment) the scroll lock key does not even light the led (when the led is available on the keyboard), you have to mess around with xmodmap - I had to test with two other external keyboards, at first I thought the led was faulty.

Anyway, I added the use of the scroll lock key on top of the previous development, but if you prefer the scroll lock to be the only toggle I can easily remove the settings-based implementation.

Current behaviour becomes:

• when the "Use arrow and PgUp/PgDown keys to scroll" setting is checked, the cursor/page keys are used exclusively for scrolling
• when the setting is unchecked, they can be used as key combinations for VC components and at show time the scroll lock key toggles between normal behaviour and scrolling
  Note that the scroll lock indicator led will not be in sync with the behaviour since managing it cross-platform is another big but separate mess.

Please, let me know what do you think about this new version.

[mcallegari]

If I had to do it, I would have added a toggle button in the Virtual Console toolbar with the existing locker icon (the one used in show manager)
When locked, the VC will not scroll. As easy as that.
I haven't reviewed your PR yet since it is quite large for what it does.
Can you please describe your changes briefly?
Thanks

[yestalgia]

Hell yeah bring back the scroll lock!

[Pac72]

@mcallegari, I tried to follow your suggestion, but it does not work here, since the change is relevant in operate mode, when console toolbar is not available.

A lot of time passed since the beginnig of this change, so I think a little recap is needed.

@lightyou opened issue #1443 because he could not use PgUp/PgDown and arrows as keyboard shortcuts.
In the steps to reproduce, he mentioned buttons, so I made a first fix that allowed PgUp/Down/arrows to be used as keyboard shortcuts for buttons (PR #1584, exactly 1 year ago :D ).
He tested the change and pointed out that it did not cover controls other than the buttons.
Hence, I produced the change in this PR, that allows binding the Pg/arrow keys as shortcuts for all controls, but, afraid that other users could rely on the original behaviour (Pg/arrows scrolling VC), I introduced a flag to choose whether to stick with the previous behaviour or switch to the new one (Pg/arrows that can be used as shortcuts).
Two weeks ago @yestalgia proposed the use of Scroll Lock, so I made a new change, allowing, at design time, to override Pg/arrows behaviour with Scroll lock even when the setting is "use Pg/arrows as keyboard shortcuts and not to scroll around".
With this change, the behaviour is:

• design mode: Pg/arrows scroll around
• oerate mode:
  • if setting is "use Pg/arrows to scroll" -> Pg/arrows scroll and do not work as key bindings
  • if setting is "do not use Pg/arrows to scroll" -> Pg/arrows can be used as shortcuts in controls, BUT Scroll Lock allows switching to scrolling and back

Changes in current branch:

• AssignHotKey ui used a QLineEdit to capture keyboard shortcut; this control consumes a lot of keys that therefore cannot be used for shortcuts; I replaced it with a simple QLabel that does not consume any key (commits dd5e3c0 and 5413a7e)
• in VirtualConsole, use a new custom VCScrollArea instead of the standard QScrollArea to have control over key events; introduce a setting to control whether to use Pg/arrows to scroll or as shortcuts (commit 1f1409b and e0183cc)
• in operate mode, even when Pg/arrows are configured to be used as shortcuts, allow using them to scroll around pressing the Scroll Lock key (commit 89a98a6)

[mcallegari]

@Pac72 thanks for your work and your recap.
To be honest though, I'm still thinking if I want to drag this in.
14 files changed because one single user cannot use 2 keys sounds just too much to me.
Plus this should eventually be ported to v5 too.

Over the years I've come to the conclusion that each and every user would like to have a different version of QLC+ tailored for their workflow.
This is obviously not possible, and if we listen to every single request, this software would already have 1000 options and therefore it would become difficult to learn and eventually unusable.
Sorry but this is how I see it.

[lightyou]

Hello. As the requester for #1443, I can give my opinion.
Personally I moved away from QLC+ since few months, for several reasons that are not the purpose of this PR, so do not do it only for me. I completely agree that the software shall stay simple enough for common usages, to keep maintenable in the long term.
On other hand, the current behavior is, in my opinion, clearly a bug (as some keys are managed diffently than some others). So this can be either fixed or clearly documented.

Regarding my personal use case, it is to use remote control used for PowerPoint like tools, that send key strokes pgup and pgdown. I have no idea if this use case can become common or not...