Yeah, unfortunately this is a known limitation at the moment. This is something we will enable in a future update.

I understand this is potentially a hard one to solve, but I feel like I need to pile on. I just upgraded to Windows 11 with excitement about WSLg, to find that the experience is quite inferior to the way it was working for me in Windows 10 with VcXsrv.

(Edit: relatively quick window resizing, Windows-style titlebars, Windows cursors, and Window snapping (even with FancyZones) was working 100% in VcXsrv.)

Not being able to quickly snap my X11 windows (primarily Emacs) to half the screen like I do with everything else is pretty bad. Window resizing itself is a lot slower, and because we now see the X11 cursors, even the resize cursors are harder to see.

From a pure usability standpoint I fail to see how this is an improvement. I really hope we can figure out a middle ground on this. The snapping especially!

Edit 2: since posting this I have also found that resizing an X11 Emacs window frequently “crashes.” It seems that the display is getting disconnected (when run from the terminal, there is no error output when this happens), but the process also ends. This is simply not usable for me… Attempting to grab the window to resize it often doesn’t work at all, takes a couple tries, and then crashes. I will have to go back to running in the terminal until this is all resolved, which is really disappointing.

Any news on this issue? I know you’re probably incredibly busy, but I would like to tell you that I would greatly appreciate this functionality. I’ve tried using both x410 and VcXsrv with some success but they both come with different pros and cons and I don’t feel like investing the time necessary to make either of those perfect. WSLg works great for me except for this annoyance.

In my particular use case, I run my entire developer environment in WSL2 and open Jetbrains Rider with WSLg. It works but I would really like to have the same window management as the rest of my Windows applications. That being snapping to edges, being able to use Win + arrow keys, and Fancy zone support.

would also like to see this issue fixed specifically for fancy zones support

In WSL terminal try to add this:

gsettings set org.gnome.desktop.wm.preferences button-layout ":minimize,maximize,close"

and you should be able to see minimize/maximize buttons on your WSLg windows

I have a WSLg (X11) app that starts with the top of the frame off the top of my monitor. I can’t find any way to move it down, since keyboard window moving doesn’t work with WSLg!

Hope this feature can be implemented soon. It has been more than one and a half year.

According to the blog post here : https://devblogs.microsoft.com/commandline/wslg-architecture/ this is not yet possible.

For example, the preview still uses server-side window movement and resizing, resulting in window 
move and resize operations which don’t feel as smooth as native, which also results in the inability 
to snap Linux windows on the edges of the monitors or to custom snap region.

@phpmypython, yes, you can download it by wsl --update --pre-release, for reference, below is the release I’m on currently, thanks!

WSL version: 1.3.15.20 Kernel version: 5.15.90.4-1 WSLg version: 1.0.56 MSRDC version: 1.2.4485 Direct3D version: 1.608.2-61064218 DXCore version: 10.0.25880.1000-230602-1350.main Windows version: 10.0.22621.2283 MSBuild version: 1935 Commit: 0e78d9c0 Build time: 22:26:39 Jul 31 2023

+1

My complaint here is mainly that the most “native experience” of X11 programs running on the Windows desktop is offered by either VcXsrv or X410 (which I switched to after encountering some performance issues in VcXsrv). X410 is a great product that performs extremely well, but it is also a commercial product. Though VcXsrv is free, it also requires tedious configuration.

If I could be so bold as to summarize this entire thread so far, I believe that what we are asking for is a native Windows experience for X11 applications on the desktop without installing and configuring third-party or commercial tools. WSLg held the promise that Microsoft would support X11 applications natively on the Windows desktop, but it falls short of that in terms of UX.

This may indicate that the WSLg architectural approach is incorrect or inadequate to address this need. I would greatly appreciate some redirection from the team if there is a different project where this issue might be filed.

“Built-in” is only valuable insofar as it provides a baseline of usability and this thread is an assessment of where that baseline is, at least for those of us willing to come here and engage. My hope was that Microsoft would back a solution that would meet or exceed what was out there already (that we were happily using). I still have that hope.

@Kermit, window snapping by keyboard, such as Win+Left or Right arrow key is supported in the latest implementation of WSLg, but window snapping by mouse, such as by dragging to monitor edge, is not supported yet though, thanks!

Windows 11 22H2 has made further improvements on the “Snap layouts” feature - press “Windows key + Z” and windows can be moved around just with the keyboard (see https://pureinfotech.com/windows-11-22h2-new-features/ section “New Snap layouts drop menu” onwards)

Alas, none of the WSLg hosted windows participate in this feature.

Please, do enable WSLg hosted windows such that they can be “snapped” around.

I figured out my stuck in maximized/full-screen issue!

In my specific scenario (GitKraken) you can toggle fullscreen with Ctrl+Shift+F, https://stackoverflow.com/questions/44543089/gitkraken-how-to-exit-fullscreen-mode.

In the current stable version that i have:

WSL version: 1.2.5.0
Kernel version: 5.15.90.1
WSLg version: 1.0.51
MSRDC version: 1.2.3770
Direct3D version: 1.608.2-61064218
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22621.2283

the only key binding that kinda works is win+up and win + down. ATM this only makes the window maximized, window or minimized. It is still missing the horizontal split and win + left/right simply do not work in this version.

+1

+1

Intellij in wslg has a problem when “Move newly created windows to their last known zone” is enabled: menu dropdowns appear in the top left of the screen, but interaction with them behaves as normal (so you have to guess where to click). Disabling this setting in FancyZones instantly solves the problem.

This may be a separate issue, but could be related so I thought worth mentioning.

@hideyukn88 it’s awesome! It doesn’t work with FancyZones (you can move normal window from zone to zone with CTRL-Arrow shortcut but WSLG windows doesn’t change size and become not usable) but after disabling FancyZones I can snap WSLG window to left or right edge. I don’t know how hard it was to make it possible but I’m really happy for this progress.

@hideyukn88 and @spronovo do you have any roadmap for this functionality? I think it’s last thing I really wait for. Using Linux apps with FancyZones or GlazeWM will be killer!

I understand this is potentially a hard one to solve, but I feel like I need to pile on. I just upgraded to Windows 11 with excitement about WSLg, to find that the experience is quite inferior to the way it was working for me in Windows 10 with VcXsrv.

(Edit: relatively quick window resizing, Windows-style titlebars, Windows cursors, and Window snapping (even with FancyZones) was working 100% in VcXsrv.)

Not being able to quickly snap my X11 windows (primarily Emacs) to half the screen like I do with everything else is pretty bad. Window resizing itself is a lot slower, and because we now see the X11 cursors, even the resize cursors are harder to see.

From a pure usability standpoint I fail to see how this is an improvement. I really hope we can figure out a middle ground on this. The snapping especially!

Edit 2: since posting this I have also found that resizing an X11 Emacs window frequently “crashes.” It seems that the display is getting disconnected (when run from the terminal, there is no error output when this happens), but the process also ends. This is simply not usable for me… Attempting to grab the window to resize it often doesn’t work at all, takes a couple tries, and then crashes. I will have to go back to running in the terminal until this is all resolved, which is really disappointing.

I realize this is quite a late response but my solution to this, for emacs, is using xdotool bound to alt+left/right to snap the emacs program to the edge. Snapped to the left edge and taking up half the monitor, for example,

(defun snap-frame-to-left ()
  (interactive)
  (shell-command "xdotool getactivewindow windowmove 0 0")
  (shell-command "xdotool getactivewindow windowsize 960 1080"))

(global-set-key [M-left] 'snap-frame-to-left)

Is there any workaround like this for the offscreen-window problem?

Could we just go the Linux route and get wslg to use a window manager like sway/mutter/kwin?