Add support for Windows virtual keyboard

[10110111]

Description

This adds support for calling osk.exe to get an on-screen keyboard whenever a QLineEdit, QComboBox or QDoubleComboBox are in focus, and closing the keyboard window when they are out of focus. This is not the normal keyboard provided by TabTip.exe, the Touch Keyboard and Handwriting Panel, but instead the Accessibility On-Screen Keyboard.

While the normal keyboard may be possible to use, the method is undocumented and may break in newer Windows versions, including by crashing the app implementing it (because of relying on a particular undocumented ABI). So this PR doesn't do this.

Fixes #4478

Screenshots

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• This change requires a documentation update
• Housekeeping

How Has This Been Tested?

Test Configuration:

• Operating system: Windows 11 Home

Checklist:

• My code follows the code style of this project.
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation (header file)
• I have updated the respective chapter in the Stellarium User Guide
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[github-actions]

Great PR! Please pay attention to the following items before merging:

Files matching src/**/*.cpp:

• Are possibly unused includes removed?

This is an automatically generated QA checklist based on modified files.

[gzotti]

Just tried.

• With the F3 search (lineEdit), it seems reasonable. After entering, keyboard does not vanish though.
• With time panel, clicking the day up-arrow calls the keyboard and then repeats the up-arrow click action, i.e., day continues to increase. One could argue to call the keyboard (limit to numbers?) when the click is exactly in the number field. I also dislike the obtrusiveness. The time panel can be left on screen, but preferably without keyboard.

Does anybody really need it? Or is it technical debt that just has to be maintained for the sake of it? As found in #4478 the operating system's virtual keyboard does work after all.

[10110111]

After entering, keyboard does not vanish though

As long as the focus is in the input field, the keyboard stays. All as expected.

Does anybody really need it? Or is it technical debt that just has to be maintained for the sake of it?

I'm not really sure. Since even the OP of the issue says that the solution without this PR is sufficient, I don't think we need this anymore. (And a downside of this accessibility keyboard is that it's slower than the normal one.)

[gzotti]

As long as the focus is in the input field, the keyboard stays. All as expected.

The panel is configured to vanish after search. So, the dialog is hidden, just the keyboard covers 1/3 of tablet screen. Testing this on my big screen, I have not checked how this appears on the small notebook. Maybe the kbd even covers the dialog?

If you also are in doubt, I agree to close it.