-
Notifications
You must be signed in to change notification settings - Fork 318
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
WSLg windows do not work with window-snapping (to sides or quarters) #22
Comments
According to the blog post here : https://devblogs.microsoft.com/commandline/wslg-architecture/ this is not yet possible.
|
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). |
In WSL terminal try to add this:
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. |
Still the same issue. |
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:
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 |
With the switch to emacs 29.1 it now supports Pure GTK (pgtk)[^2]. This allows better integration with Wayland running in WSL. One thing that's still missing is proper window "snapping" and tiling management[^1], but I mostly run it in fullscreen mode. [^1] https://batsov.com/articles/2021/12/19/building-emacs-from-source-with-pgtk/ [^2] microsoft/wslg#22
I realize this is quite a late response but my solution to this, for emacs, is using (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 |
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 version: 1.3.15.20 |
Upgraded to the pre-release now and this seems to work like a charm! 🎉 |
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:
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. |
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!
|
Thanks so much! It works as it is now.
|
@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. |
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. |
@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 |
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.
The text was updated successfully, but these errors were encountered: