-
Notifications
You must be signed in to change notification settings - Fork 6.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FancyZones does not recognize WSLg and WSA (Android) windows #10942
Comments
@enricogior this is something we'll have to get working |
@crutkas |
kicking off emails :) |
@crutkas |
related: microsoft/wslg#22 |
@itsme-alan |
Is this feature going to be implemented any time soon? |
Absolute need this with my ultra-wide screen! |
I discovered GWSL just after posting this and it does everything we'd expect WSLg to do, and has done so for a while. Edit: You can find it on the Windows Store. |
@tinkerpunktheprol Thank you very much, in the past I use Xming, that is free and works too, or X410 , But, this repository is about PowerToys and this issue about WSLg. |
WSLg have a very good compatibility with vGPU, not available on old classic x11 forwardings like Xming. |
@crutkas it's possible to snap WSLG window to the screen edge (only with keyboard, mouse snapping still doesn't work). Does it change anything for this task? Moving window between zones just with keyboard would be super useful. |
Would it be possible to have FancyZones refuse to move WSLg windows? For me FancyZones seems to move the windows visually, but the window itself (the x server?) isn't aware of the move/resize, so mouse interaction breaks. I'd rather have FancyZones refuse the attempt instead of ending up in a broken state. (workaround if you're trying to get out of this broken state: for me WIN+ up-arrow sets the WSLg window to full screen, and then WIN+up-arrow moves it back to the "correct" place on the monitor visually, which aligns with what the x server thinks, so mouse interaction works again.) (e: styling issue) |
For me, with FancyZones enabled, dialogue windows created by WSLg apps (e.g. Intellij) appear in a different place to their interaction area if I have "Move newly created windows to their last known zone" enabled, and appear correctly if it's disabled. With the setting enabled, dialogues all appear in the top left of the screen, but the interaction area remains wherever they're supposed to be. No other FancyZones settings make a difference, apart from disabling FancyZones altogether which has the same effect as disabling "Move newly created windows to their last known zone". |
The issue persists. Is there any progress on fixing this? Or is the only solution to buy a third-party tool like GWSL? |
Microsoft PowerToys version
0.35.0
Running as admin
Area(s) with issue?
FancyZones
Steps to reproduce
Bug: The zones will not show and the X11 app will not resize to a zone.
Bug: The zones will not show and the X11 app will not resize to a zone.
PowerToysReport_2021-04-25-17-01-31.zip
✔️ Expected Behavior
X11 apps have worked since WSL1. There was additional work which needed to be done that WSLg helps solve and improves. For WSL1 and WSL2 before WSLg, you had to run an X-Server and set the
DISPLAY
environment variable, and this would show the window. Kali Linux has a Windows executable available in the distro which is rather ingenious,kex
, via which Kali bundles a Windows X-Server within WSL and can launch in several modes, notably one which is "seamless" and opens a window very similar to WSLg in that it looks like another Windows application, and there is another mode which works through RDP similar to how WSLg seems to be doing it.The expectation with X11 apps launched via WSLg is that they'd perform the same way as Kali's seamless, with respect to how they'd work with FancyZones. X11 apps moved to different zones snap as expected, like other Windows applications.
❌ Actual Behavior
With WSLg, this does not work. Fancy Zones does not recognize that the hotkey is being pressed and does not provide zones, so it will not snap. Since applications running through WSLg respond like any other application on Windows, it would be expected that zone snapping would work as well. Launching an X11 app through one of the WSLg Start Menu icons seems to expose itself slightly differently to Windows as inspected with Process Explorer, but both behave the same way.
It seems very likely that WSLg is swallowing the hotkey event required for FancyZones to work and/or because the window doesn't expose itself to the process tree in the same way as WSL1 and earlier WSL2 methods of getting X11 applications running, that providing this functionality is actually a WSL issue rather than FancyZones, but this is notably different behavior than expected considering how it worked before with VcXsrv configurations.
Other Software
Windows 10 Pro 21364.co_release.210416-1504
Kali Linux (PS > WSL -d kali-linux)
The text was updated successfully, but these errors were encountered: