Open trws opened 3 years ago
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.
Yeah, unfortunately this is a known limitation at the moment. This is something we will enable in a future update.
I wonder if there is some way of making new snapping feature on Windows 11 to work on WSLg windows. I haven't tested it yet and I don't think it will work.
Can second this with alan, I really hope something like this could be achieved with Windows 11's reworkings.
Could we just go the Linux route and get wslg to use a window manager like sway/mutter/kwin?
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!
WSLg apps were working great for me for a while, however they now are being created off screen and I have no way to bring them into a visible area.
A more severe issue is that when you maximize a window, there is no way back to unmaximize it or to resize it (tested with gnome application such as gedit or gnumeric). Or did I miss something?
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
Well that worked, thanks, absolute lifesaver :)
Is there any workaround like this for the offscreen-window problem?
I forgot to comment, but for me adding the maximize/minimize buttons does not solve my problem: once a window is maximize, it is not possible to reduce or resize it anymore, the window is stuck in fullscreen.
I agree with @parrenin, and also note that adding the buttons doesn't solve the core issue, which is that once a window comes up with its title bar off screen, there's nothing you can do at all.
I'm stuck in full screen too, been using my Linux GUI apps for months fine but suddenly today it's stuck in full screen mode. Unsure if related but it's broken from dropdowns from within the application too (GitKraken).
How do you know if your WSL distro is using GNOME? I'm using Ubuntu currently. Is there a GNOME command to reset the state of an application? Or is this a WSLg bug?
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.
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.
Pure GTK (pgtk) got merged into emacs 29 thus you can compile emacs 29 with support GTK support which avoids many of the X11 emacs crashes you're experiencing. Here's a blog post by Emacs Redux showing how to get emacs working on WSL2 without the crashes you're experiencing: https://emacsredux.com/blog/2021/12/19/using-emacs-on-windows-11-with-wsl2/#fromHistory
I think #727 is something very close to this issue, or even the same.
I recently upgraded to WSL-0.61.8.0/WSLg-1.0.39 and I get a strange behavior.\ When I launch Gnumeric for the first time after login, I get a different header bar than the usual gnome one, and I can maximize/un-maximize as expected. Also, the Gnumeric icon appears normally in the taskbar (#614). But the Gnumeric window does not scale correctly (it is blurry with a 200% scaling).\ Then when I launch Gnumeric subsequently, the Gnumeric window scales properly, but I do not get the correct header bar and icon in the taskbar.
Still the same issue.
Hope this feature can be implemented soon. It has been more than one and a half year.
would also like to see this issue fixed specifically for fancy zones support
+1
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.
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 saw there was a release of WSLg but nothing yet fixing this issue.
+1
Unfortunately WSLg doesn't seem to support this feature. Applications from WSL are not utilizing the native Windows UI so snapping doesn't work this way.
But I'm using an alternative XServer for about 1 1/2 years now which comes the intended behavior and even gives me the possibility to pin apps to the task bar and start them with a click onto the app icon.
I'm using MobaXterm with the following settings in my .zshrc:
# Display for XServer
# https://mip-cloud.gitlab.io/post/2020/10/idea-in-wsl2/
export LIBGL_ALWAYS_INDIRECT=1
export DISPLAY="`grep nameserver /etc/resolv.conf | sed 's/nameserver //'`:0"
Despite some minor issues this setup works great but I'd expect that the integrated XServer from MS works the same way so that you don't have to utilize 3rd party tools for this.
Unfortunately WSLg doesn't seem to support this feature. Applications from WSL are not utilizing the native Windows UI so snapping doesn't work this way.
But I'm using an alternative XServer for about 1 1/2 years now which comes the intended behavior and even gives me the possibility to pin apps to the task bar and start them with a click onto the app icon.
I'm using MobaXterm with the following settings in my .zshrc:
# Display for XServer # https://mip-cloud.gitlab.io/post/2020/10/idea-in-wsl2/ export LIBGL_ALWAYS_INDIRECT=1 export DISPLAY="`grep nameserver /etc/resolv.conf | sed 's/nameserver //'`:0"
Despite some minor issues this setup works great but I'd expect that the integrated XServer from MS works the same way so that you don't have to utilize 3rd party tools for this.
Do you mean we don't have to install an 3rth party XServer? Just put the two lines in the rc file and it will work? Thanks!
Nope, mobaxterm has its own xserver. And MS have no xservers, it's Weston + rdp
+1
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)
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.
@aaronbieber Maybe as an alternative to X410 have a look at GWSL as it uses VcXsrv with some sugar added to it and it works great from my experience. Of course this shouldn't be needed at all with a proper fix for this issue but with not seing it fixed in near future all workarounds should be considered
+1
(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)
This only works with XWayland I guess... any similar workaround for pure wayland applications (e.g. emacs pgtk)?
@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!
@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!
@hideyukn88, do you mean the latest implementation that's widely available or the latest implementation that's on an insider build?
@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
Upgraded to the pre-release now and this seems to work like a charm! 🎉 emacs
pgtk
build is now looking wonderful and smoothly integrated in Win11 with no X11 hacks. To me, this is a huge quality of life improvement.
@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
I just performed this update and I'm still unable to snap windows for an application like google chrome or firefox using the WIN + left/right arrow key.
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.
window snapping by keyboard, such as Win+Left or Right arrow key is supported in the latest implementation of WSLg
no idea how I could have missed this but thank you! been waiting for this since forever!
@RiccardoManzan, you are on public release version (1.2.5.0), currently it's only supported with pre-release version, thanks!
WSL version: 1.2.5.0
Thanks so much! It works as it is now.
PS C:\WINDOWS\system32> wsl --version WSL 版本: 2.0.0.0 å†…æ ¸ç‰ˆæœ¬ï¼š 5.15.123.1-1 WSLg 版本: 1.0.57 MSRDC 版本: 1.2.4485 Direct3D 版本: 1.608.2-61064218 DXCore 版本: 10.0.25880.1000-230602-1350.main Windows 版本: 10.0.22621.2215
@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.
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.
I agree with @parrenin, and also note that adding the buttons doesn't solve the core issue, which is that once a window comes up with its title bar off screen, there's nothing you can do at all.
@garyo I have an application window that appears between my laptop's screen and an external screen with different scaling ratio and I cannot move the window or interact with it. I use a way to work around this. I use win
+ Tab
to the multi-task view and force the wslg window to stick to the left or right side of my screen. Then I can move and interact with the wslg window. Not stable though ...
This is great progress with Win+Arrows working now, but dragging the title bar needs to work. Hopefully this becomes a possibility soon.
Environment
Steps to reproduce
Expected behavior
The window snaps to the side indicated, or in the case of snapping another window appears in the list of windows available to be snapped to the remaining space.
Actual behavior
The window stays where it is, or in the case of snapping another window the WSLg window does not appear in the list of windows available to use the remaining space.