Miscelaneous improvements and fixes

[lkc-rc]

• Fix an issue where the compositor wasn't actually minimizing redraws
• Add support for Qt > 6.7
• refactor keyboard handling code in its own class
• fix a few minor keyboard handling issues
• Add two strategies to enable interoperability with qtwebengine using keyboard layouts other than US qwerty

[hardening]

This masquerade_xcb build option is not clear to me. I feel like:

1. this could possibly be a runtime option
2. if we really need different plugins, we could build 2 plugins from the same sources with different defines, or I'm missing something ?

[lkc-rc]

Okay so:

1. I think Q_PLUGIN_METADATA in main.h needs to be set at moc compilation time, and it can apparently only be used once in the code (https://doc.qt.io/qt-6/qtplugin.html#Q_PLUGIN_METADATA). Beyond that, I'm not sure how to parametrise src/plugins/platforms/freerdp/main.cpp for runtime configuration.
2. I mean, we could, but masquerade_xcb is a terrible hack that would probably break normal users' installs. The point of this feature is to replace the actual xcb plugin with qfreerdp under xcb's name, so that qtwebengine uses its better native keyboard event handling codepath. To me, building this version of the plugin by default would be putting users at risk of breaking their Qt install.

[hardening]

For 1 (runtime option), that could take the form of two different keyboard handling classes. When I've seen the changes that were moving the keyboard handling to its own class, I though that mKeyboard would be a pointer to a class instantiated at runtime (so either to a normal one or a xcb maquerade one).
Also a single plugin can export multiple names, that's why you have QFreeRdpIntegrationPlugin::keys, QFreeRdpIntegrationPlugin::create so that could be parametrized at runtime (if the requested name is freerdp_xcb, we would instantiate the platform with the corresponding keyboard)

[lkc-rc]

That indeed sounds way better, I just wasn't able to make that happen with my limited knowledge of qt platform plugins.

We just need to make sure that QGuiApplication::platformName() returns exactly "xcb" (https://github.com/qt/qtwebengine/blob/603a1809481eb4d4ca972f0f64915d29fb99f53b/src/core/web_event_factory.cpp#L95).

Also, there is no need for a second qfreerdppeerkeyboard class, because the single one already behaves correctly by setting nativeScanCode, nativeVirtualKey, and nativeModifiers in QKeyEvent. It's just that qtwebengine refuses to use them if you're not called "xcb" (or "wayland") :/

Do you, by any chance, have additional documentation on QPlatformIntegrationPlugin ?

[hardening]

That indeed sounds way better, I just wasn't able to make that happen with my limited knowledge of qt platform plugins.

We just need to make sure that QGuiApplication::platformName() returns exactly "xcb" (https://github.com/qt/qtwebengine/blob/603a1809481eb4d4ca972f0f64915d29fb99f53b/src/core/web_event_factory.cpp#L95).

Also, there is no need for a second qfreerdppeerkeyboard class, because the single one already behaves correctly by setting nativeScanCode, nativeVirtualKey, and nativeModifiers in QKeyEvent. It's just that qtwebengine refuses to use them if you're not called "xcb" (or "wayland") :/

Do you, by any chance, have additional documentation on QPlatformIntegrationPlugin ?

Nope, but you can look at the code or if you set QT_DEBUG_PLUGINS env variable, you will see tons of logs of the plugin loading process, that usually helps (also that's so verbose that you set it once when debugging and then remove it)...

[hardening]

Would be nice if you could rebase your PR on master, I've added CI checks on the repo so that we can test builds with Qt 5 and 6.