Incorrect menu placement in Qt 6 applications

[Aerocatia]

Environment

Windows build number: Windows 11 build 10.0.22000.318
Your Distribution version: Arch Linux (installed roughly as per https://github.com/nckslvrmn/arch_linux_wsl2) *mesa-d3d12 is installed from the AUR
Your WSLg version: 1.0.26 (store preview)

Steps to reproduce

Run any Qt6 application with menus. Open a menu and it will be offset by some amount. If using multimon and the program is on a second monitor the menu can be completely out of bounds.

Expected behavior

CMake GUI:
Note: CMake GUI saves something in its config file that happens to work around this issue. It will work as expected after the first run and ~/.config/Kitware/CMakeSetup.conf is created.

Actual behavior

CMake GUI (First Run):

A GB emulator (Always):

[hideyukn88]

@Vaporeon, thanks for reporting the issue. I tried CMake GUI, but I was not able to reproduce the issue. I also created some application with dropdown menu with Qt Creator (with Qt 6.2.2), but no repro either (below screen capture). Although, we are aware of similar issue with Qt 4, reported at #459, it's possible same root cause. If you have a chance to try out other Qt 6 applications, please let us know how it goes. Thanks!

I have the same issue when using python (3.10.6) and PySide6.

[hideyukn88]

@Maccalariat, would you please share the output from wsl --version? I'm not familiar with this app, but I don't see the menu offset issue, do I need some step to reproduce? Thanks!

Hi hideyukn88. I can't run 'wsl --version'. That's not a valid command for me (?). Running wsl --status results in:
`Default Distribution: Debian
Default Version: 2

Windows Subsystem for Linux was last updated on 8/08/2022
WSL automatic updates are on.

Kernel version: 5.10.102.1`
I am running a custom-written python app.
Here's a screenshot of the app and the 'offset' issue

The options for the first combobox appear vertically displaced. Each run of the app has the options appear in a different location. There is no issue if the same code is run in windows (windows python etc).
regards,
Hans

I tried using the cmake-gui app to discount my badly-written code (entirely a possibility). As you can see, the same issue.

hope this helps.
Hans

[hideyukn88]

@Maccalariat,

I can't run 'wsl --version'. That's not a valid command for me (?).

This indicates you are using very old version of WSL, please update it from aka.ms/wslstorepage, and try again, thanks!

Thank you hideyukn88. I had previously manually uninstalled, reinstalled wsl. I guess I messed that up. I updated the installation as you said. The output from 'wsl --version' is:
C:\WINDOWS\system32>wsl --version
WSL version: 0.65.3.0
Kernel version: 5.15.57.1
WSLg version: 1.0.41
MSRDC version: 1.2.3213
Direct3D version: 1.601.0
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22000.856

.. hope I got it right this time.
Having update wsl and re-installed a fresh Debian, I still get the same issue running cmake-gui.
regards,
hans

[hideyukn88]

@Maccalariat, thanks for info, I did remove previous Debian and reinstalled it, but I can't reproduce the issue with cmake-gui, but I noticed your screenshot is showing your cmake-gui version is 3.24.0, while mine is 3.18.4, have you installed it other than debian's package repo? thanks!

Hi hideyukn88,
I installed cmake from debian testing. My installation is a full-upgrade from stock to testing release. I see from the OP that the cmake release was 3.22. Could it be that the debian testing has issues?
I did a fresh debian bullseye install, apt update/upgrade and apt install cmake-qt-gui. It installed 3.18.4. Alas, same issue.
hans

[hideyukn88]

@Maccalariat, I built cmake-gui from source, and now it's 3.24.0, which seems the latest release, and it is confirmed it's using Qt6, but I still haven't been able to reproduce, but given you also can reproduce with Debian bullseye and 3.18.4, the reproduce factor should be something-else.

Hi hideyukn88,
I tried another python app that I had written, this time using Tkinter - which does not use Qt. There were no problems with menu placement. I tried a number of other examples of tkinter and all worked fine. I have a suspicion that the problem lies with Qt. That may not be surprising since the framework is half-an-os on its own.
For me, I'll probably bail on Qt.
regards, Hans

[BAndiT1983]

Stumbled upon same issue in QtDesigner 6, was pretty reproducible by maximizing and minimizing/restoring previous window size. Menus start to wander off, which wasn't obvious at first, thought that the menus stopped working, but after a while discovered them being placed off-screen (after minimizing the window to previous size again).