I recently wanted to test an extension build on Linux and used Windows 11 WSL2 for this with a Slicer build from scratch on the main branch.
Everything builds smoothly (which is really great) and GUI support accross WSL 2 worked out of the box (I may have set-up something at some point but I’m not entirely sure).
While testing in this environment, I noticed the following behavior for the Slice views floating menus :
The position of the floating menus is not correctly anchored and it’s impossible to click on the different options.
I have seen this behavior only for the view menus (2D and 3D widget) and not for the “standard” QMenu options.
This problem is not really blocking or anything and it’s not the expected way to run 3D Slicer but I wanted to know if others have seen / fixed this behavior.
I’ve tried this and it seems that popups generally appear at the correct location. I’ve found that only the Welcome window, slice view controller (and maybe the volume rendering preset selector) is not at the right place.
There are a lot of mappings between local widget and global coordinates when positioning the slice view controller popup base class, probably some of those calls don’t work correctly in WSLg. It would be nice if you could debug what goes wrong. You can access all widgets and their methods in Python, so you could investigate this without configuring a C++ debugger.
Thanks for the information. It indicates that the root cause of thr issue is that WSL2 works incorrectly, or at least differently than a linux desktop. The problem will likely to be fixed in WSL2, but probably some workaround could be inplemented in Slicer as well.
However, it is hard to justify spending time with investigating this, when Slicer runs natively on Windows, including all AI tools, with GPU acceleration, etc. What is the motivation for running Slicer on Windows via WSL2?
On my end, the main reason for using 3D Slicer in WSL2 was for two things :
Testing / evaluating extensions which may not be available on Windows. That was the case for one of the modules from the AMASS extension for mesh segmentation which relied on pytorch 3D which was not available on Windows then (not sure if it has changed since).
Dev purposes to make sure extensions developed on Windows also work as expected on Linux (for this I could also use a dual boot / VM)
So the only use case which would be relevant would be the first one but I don’t think this would justify the time investment.
Thanks for the information. Quick testing on Linux is a good use case, as it is simpler than setting up dual-boot or GPU-accelerated virtual machine on Windows. For quick testing, the popups appearing at incorrect location/not working is probably tolerable as there are workarounds (the same features are available in docking widgets, which work well).
Fornl future reference, related issue in the issue tracker:
