Improve WSL 2 support

[jankoprowski]

What is the problem or limitation you are having?

Hello,

Under this issue I would like to track PRs improving WSL support in Toga.
Right now, after this simple PR #4572 Toga tests are runnable but they fail.

GTK 3

FAILED tests/app/test_desktop.py::test_current_window
FAILED tests/widgets/canvas/test_canvas.py::test_reset_transform
FAILED tests/window/test_window.py::test_focus_events[Window-second_window_kwargs0]

GTK 4

=========================== short test summary info ============================
FAILED tests/app/test_desktop.py::test_current_window
FAILED tests/widgets/canvas/test_canvas.py::test_reset_transform
FAILED tests/widgets/test_button.py::test_font
FAILED tests/widgets/test_button.py::test_focus
FAILED tests/widgets/test_label.py::test_font
FAILED tests/widgets/test_textinput.py::test_font
FAILED tests/window/test_window.py::test_visibility[Window-second_window_kwargs0]

I'm working on it.

Describe the solution you'd like

I think to find a ultimate WSL/WSLg setup to makes all Toga tests passes.

Describe alternatives you've considered

We can just ignore existence of WSL 2 and do not support it.

Additional context

No response

[freakboy3742]

Thanks for the ticket. Can you provide a full test log? I can't run WSL stuff myself because my Windows machine is already being emulated via Parallels; and just knowing the list of tests that are failing doesn't give us much to work on.

On the meta-question - if we're able to support WSL2, it's definitely desirable to do so; but it will always be more of a "compatibility" option than a viable option for standalone desktop apps.

[jankoprowski]

I'm providing logs from Toga testbed GTK3 and GTK4.

gtk3.log
gtk4.log

@freakboy3742 - Please let me know if this is what you expected.

Regarding WSL2 support - did you considered best effort community support?

Logs were recorded by script command so to best way is to cat them into the console and pass to some less or other pager.

[freakboy3742]

gtk3.log

• FAILED tests/widgets/canvas/test_canvas.py::test_reset_transform

This one isn't entirely unexpected - it's comparing an actual image to a reference image, but there's lots of factors that can impact whether the image is exactly the same. The test logs says "Saving to /home/johny/.local/share/testbed/canvas" - that folder will contain the image that was actually rendered; we'd need to compare that against the reference image in the testbed/reference folder to see if there any discrepancies that are a source of concern, or if it's a case of WSL rendering something slightly different (at the subpixel level). The reset transform test is particularly prone to problems here, because it depends on the platform's exact interpretation of the line dash algorithm when it comes to corners in a polygon.

In this specific case, it might even be that the wrong reference image is being used; if Toga under WSL is identifying as GTK, it might be using the GTK reference image rather than the Windows one (or vice versa)

• FAILED tests/app/test_desktop.py::test_current_window
• FAILED tests/window/test_window.py::test_focus_events[Window-second_window_kwargs0]

These two both look like issues changing focus between windows. That might be related to Wayland (which has... opinions... about what you can tell a window to do); or it could be a simple issue of the test not waiting enough. The next step for these will be to run those test with --slow and visually inspect what they're doing; and/or try and reproduce what the test is doing in a standalone app to see if the issue is the test, or something in the implementation.

gtk4.log

These look to be the same failures, but with these ones as well:

• FAILED tests/widgets/test_button.py::test_font
• FAILED tests/widgets/test_label.py::test_font
• FAILED tests/widgets/test_textinput.py::test_font

These look like a sizing issue - the test is asserting things like "probe.width > orig_width", and the width hasn't changed. That looks like a genuine failure - the test is setting the font size to 30, which should be changing the size of the font (and thus the test). Again, running this with --slow will be the first test, to check whether the font size is actually changing and the probe is failing to detect it, or if there's something else going on.

• FAILED tests/widgets/test_button.py::test_focus

I'm assuming this is a copy-paste failure? This doesn't appear in the log you've provided.

Regarding WSL2 support - did you considered best effort community support?

I'm not sure what you're asking/suggesting here. Support of any Toga platform is always "best effort community support".

What I was trying to suggest is that WSL is unlikely to ever be a "first class" platform implementation. Supporting Windows the way most users experience Windows out of the box will always be the priority. Supporting WSL will always be a nice-to-have for compatibility.

[johnzhou721]

• FAILED tests/app/test_desktop.py::test_current_window
• FAILED tests/window/test_window.py::test_focus_events[Window-second_window_kwargs0]

These two both look like issues changing focus between windows. That might be related to Wayland (which has... opinions... about what you can tell a window to do); or it could be a simple issue of the test not waiting enough. The next step for these will be to run those test with --slow and visually inspect what they're doing; and/or try and reproduce what the test is doing in a standalone app to see if the issue is the test, or something in the implementation.

Adding on to this: This also has to do with the window manager implementation—for every Linux GUI toolkit, there seems to be a certain set of window managers it works best with, and outside of that, these focus features aren't usually implemented. For Qt, a Window manager that doesn't work best with it is Mutter, which we use for testing in CI, so we remove has_focus on Wayland in Qt here:

toga/qt/tests_backend/window.py

Lines 37 to 39 in a3c9f09

	self.supports_focus = (
	False # Qt activiateWindow doesn't work with mutter used in CI
	)

So if we can detect running under WSL and disable has_focus on WindowProbe if we really can't make it work. Sometimes we just have to let it go here.

For GTK4:

• FAILED tests/widgets/test_button.py::test_font
• FAILED tests/widgets/test_label.py::test_font
• FAILED tests/widgets/test_textinput.py::test_font

There's some historical issues on Linux GTK4 regarding this aspect of widget sizing on font change; the comments around #3239 (review) in that thread was the last time I debugged those issues. There may be some helpful things in there if it's not resolved with --slow.

[jankoprowski]

gtk3.log

• FAILED tests/widgets/canvas/test_canvas.py::test_reset_transform

This one isn't entirely unexpected - it's comparing an actual image to a reference image, but there's lots of factors that can impact whether the image is exactly the same. The test logs says "Saving to /home/johny/.local/share/testbed/canvas" - that folder will contain the image that was actually rendered; we'd need to compare that against the reference image in the testbed/reference folder to see if there any discrepancies that are a source of concern, or if it's a case of WSL rendering something slightly different (at the subpixel level). The reset transform test is particularly prone to problems here, because it depends on the platform's exact interpretation of the line dash algorithm when it comes to corners in a polygon.

Here are images from /home/johny/.local/share/testbed/canvas

[freakboy3742]

Those images seem to confirm my suspicion - the code is doing the right thing, but there's sub-pixel variations in the reference images. That could be because of a quirk of your specific setup, or it could be something specific to WSL2.

Ultimately, the approach we need here is to have the testbed suite run under WSL2 in CI, and then make whatever modiifications are needed to the test suite to accommodate WSL2-specific differences.