Standardizing Win32 and vsgQt event handling with intended behavior #687
robertosfield
started this conversation in
General
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Thanks to refactor of Windows keyboard handling from @kannode the keyboard mapping so it now matches that seen on Linux/Xcb implementation with PR #669 which is now merged with VSG master. The change ensures that KeyEven;;tbaseKey for an unmodified 'a' key returns 'a' and the KeyEven;;modifiedKey remains 'a', while if you press shift 'a' then baseKey remains as 'a' but the modifiedKey becomes 'A'. This scheme is standard on X11 and was used by the OSG as well.
I have also updated vsgQt to use this convention as well with this commit: vsg-dev/vsgQt@a639068, as previously it was returning 'A' for baseKey when pressing the 'a' key.
While working on a client project that used vsgQt I came across a separate issue with how Qt handles coordinates, this was causing the window sizes and pointer events to have the wrong coordinates w.r.t the underlying Vulkan swapchain resources. It took me a while to figure out but it eventually turned out that modern Qt implements a Device Pixel Ratio on some displays (on my Kubuntu system it's defaulting to 1.25), so that the window dimensions you ask it create a scaled behind the scenes to a new value, and the mouse coordinates it passes back remain in this scaled coordinate system.
Vulkan calls a spade a space and pixel a pixel rather scaling anything behind the scenes "for" you, so rather play these pixel scale kludges the VSG simply uses the same conventions as Vulkan. To make sure vsgQt is consistent with this I have had to add remapping of window position/sizes and pointer coordinates into proper pixel sizes that relate 1:1 the underlying graphics hardware. This is done by multiply the Qt's coords by QWindow::devicePixelRatio(). This fix is provided by vsgQt commit: vsg-dev/vsgQt@98e18da.
The purpose of all these changes is ensure the various platform and windowing toolkit combinations behave the same so one event handler implementation will be portable across systems and software. If you do spot inconsistencies across platforms then let us know, where possible I'd like to iron all the issues out so we can get closer to the write once, compile and run on many platforms.
Beta Was this translation helpful? Give feedback.
All reactions