Skip to content
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

Preserve window size when restoring a maximized window #422

Closed
prasannavl opened this issue Nov 21, 2015 · 35 comments

Comments

@prasannavl
Copy link

commented Nov 21, 2015

The window size is not preserved, if VSCode is closed being maximized.
The correct behavior should be that it restore to the previous un-maximized size, when restored.

@mackenza

This comment has been minimized.

Copy link

commented Nov 21, 2015

what platform?

@prasannavl

This comment has been minimized.

Copy link
Author

commented Nov 21, 2015

Windows.

But I suspect, it should be a problem with all platforms unless the window managers override it, which could hide the problem.

@mackenza

This comment has been minimized.

Copy link

commented Nov 21, 2015

where did this standard of restoring un-maximized when you shut down maximized come from? I am on Linux (Mint Cinnamon) and every app I tried restored maximized if I shut it down maximized. I am not around my Windows machines right now so can't test there. Is this in some sort of Windows style guide item?

@prasannavl

This comment has been minimized.

Copy link
Author

commented Nov 21, 2015

I'm afraid there's really no style guide in that aspect. But Windows always properly stores the window sizes, and its a convention that's just in practice, unless an application overrides it explicitly.

This deviates from it.

Just to clarify, yes it opens maximized, if it shuts down maximized - that's correct behavior. But when you restore it now, it loses its actual size when not maximized.

Technically, its an Electron bug, where it only stores the last size, which when maximized is the maximized size instead of the restored window size. VSCode, since v0.10 works around it by setting itself to a default size instead of the old electron behavior which is worse - since it'll have the maximized size as the previous size (which is the case in previous versions - where when you unmaximize, it will have a size which is again the maximized size).

@bpasero bpasero changed the title Window size not preserved Window size not preserved when going from maximized to restored Nov 23, 2015

@bpasero

This comment has been minimized.

Copy link
Member

commented Nov 23, 2015

Yeah, known issue.

@bpasero bpasero self-assigned this Nov 23, 2015

@bpasero bpasero added bug help wanted and removed bug labels Nov 23, 2015

@bpasero bpasero modified the milestone: Backlog Nov 26, 2015

@bpasero bpasero removed the help wanted label Mar 23, 2016

@regs01

This comment has been minimized.

Copy link

commented Mar 25, 2016

This could be related
If there is any VS Code window is open, new instance resets window size to default. Still there as of 0.10.11.

@bpasero

This comment has been minimized.

Copy link
Member

commented Mar 28, 2016

Well we open any Nth window (for N > 1) in the default size, what would you expect otherwise?

@regs01

This comment has been minimized.

Copy link

commented Mar 28, 2016

well, i more expect size i want, cause i have to resize the tiny window every time i open it. just save the last size and use it always until any window get resized.

@bpasero

This comment has been minimized.

Copy link
Member

commented Mar 29, 2016

@regs01 so you would expect the second window to open with the size of the window that is already open?

@regs01

This comment has been minimized.

Copy link

commented Apr 1, 2016

@bpasero kind of. so i just resize it once and it will save my size, then any instance, no matter if 1st, 2nd or 3rd will open with my size. well, any other app does like this.

@bpasero

This comment has been minimized.

Copy link
Member

commented Apr 2, 2016

@regs01 I suggest you open a separate issue on that topic as this one here talks about a different problem.

@prasannavl

This comment has been minimized.

Copy link
Author

commented Apr 2, 2016

@bpasero I'd say that the point made by @regs01 and this are highly related. So much so, that fixing this unless explicitly overridden should fix that as well naturally.

The idea is that whenever a window is created, it should now use the last saved size. Now, the intricate detail here is that the last saved size should never be the maximized size. (If the window is maximized when it quits, it should rather save the size before maximization with an isMaximized flag). And any window that's created uses this size and flag on creation.

@prasannavl

This comment has been minimized.

Copy link
Author

commented Apr 2, 2016

Pseudocode (It doesn't reflect electron's api. Just the idea. Variables names may also be exceedingly verbose on purpose):

createWindow:

let { w, h, x, y, isMaximized } = getSavedSizeObject();
sizeTracker.setAll(w, h, x, y, isMaximized);
window.create(w, h, x, y); 
if (isMaximized) window.maximize();
window.show();

windowResize:

if (window.isMaximized) {
sizeTracker.setIsMaximized(true);
} else {
sizeTracker.setAll(w, h, x, y, false);
}

saveSize:

let { w, h, x, y, isMaximized } = sizeTracker.get(); 
saveSizeObject(w, h, x, y, isMaximized);

Note: sizeTracker is nothing but a simple in memory representation that tracks the size. Implicitly, the last window to quit wins. All the above points should be solved by adaptation of this pseudo code. And it will comply with the windows convention (and what one would naturally expect from any well behaving application). Should fit well with general Linux desktop managers as well.

If for whatever reason, a platform with weird conventions (perhaps the Mac? I have no idea) requires different handling, they can very well be hooked in the above pseudo code.

@bpasero

This comment has been minimized.

Copy link
Member

commented Apr 2, 2016

@prasannavl I am not entirely convinced that the one issue is the same as the other. your issue talks about the fact that when you maximize a window from a certain size and then restart and restore, the previous size is not restored. I see this as an actual bug we should fix eventually.

The other point is about how new windows should be sized when you open them. I am not sure there is a solution that makes everyone happy. Yes, you could just pick the window size of the window that is the last active one, but from a UX perspective we decided not to create a window with the exact same dimensions because it can make it hard to actually notice that you have 2 windows open now. That is why we decide to fall back to the default size and you will notice that any further window you open from that point will cascade the window a little bit so that they are not exactly overlapping.

Now, you could also argue that maybe the window that opens should inherit a size that was associated with that folder when you previously opened it. Imagine we would remember each window dimensions for each folder opened and restore it if you ever open that folder again. Still, this might not fix the UX issue of overlapping windows.

I would be open to discuss other solutions but I would think that discussion should happen in another work item.

@prasannavl

This comment has been minimized.

Copy link
Author

commented Apr 2, 2016

@bpasero The problem you mention can be solved this way, in a manner to keep everyone reasonably happy until more advanced configurations are added (if at all worth going through the trouble, which I don't think it is if the below can be implemented).

If its the first window opened by the application, use the same size.
If it is indeed a new one, cascade x, and y a bit. Now in order to do this, first check x + width, and y + height to make sure its not outside bounds of the visible screen. If it is, reduce the cascade values by half and try again, until its either zero, or succeeds. If all fails, now do the same thing again, with negative cascades as it approaches zero again.

The nifty little trick here, will be that, don't use the sizeTracker.setAll pseudo code above on window creation when its a non-first window. It will however work during resizes. So, the cool thing is, now the user size will always be respected, even though new windows cascade.

The new window's locations never gets saved. But the moment a user manually touches the window size, (by resize, movement etc), it gets saved as the new size.

@prasannavl

This comment has been minimized.

Copy link
Author

commented Apr 2, 2016

PS: You could also very well, just let the platform's window manager handle the secondary window positions, by ignoring the x and y completely. Windows should handle the cascading on its own (Win32 should, but not sure if electron overrides it) I would consider that as a first stage to the solution.

Aside: Isn't that how "Windows" was historically named? It managed "windows" before all the OS intricacies came into play. Let's just get out of the way and let it do what it does best! ;)

@bpasero

This comment has been minimized.

Copy link
Member

commented Apr 2, 2016

I am quite sure that the framework we use (Electron) on Windows does not provide any functionality to position the window in a clever way, but I can try again.

@prasannavl

This comment has been minimized.

Copy link
Author

commented Apr 2, 2016

@bpasero While I'm not highly familiar with electron at the moment, I do know enough to agree that it doesn't provide any clever positioning. But what I was pointing at was that, does electron let the platform manager natively handle its position, or does it override the native functionality and thereby dum it down?

If its the former, then should be easy or I'm afraid the logic that I mentioned using the cascade, or similar has to be implemented. But considering the fact that you already do cascade it, can't we just use the same cascade logic that you already do, but just with the saved size instead of the default fallback size?

@regs01

This comment has been minimized.

Copy link

commented Apr 2, 2016

I just wanted to say exactly same. It's been pretty common in Windows to cascade windows. I was saying use same size, but i didn't say anything about same position, right because of cascading.

So there is a logic that could work flawlessly

  1. First instance should open with saved size, saved position and saved state (maximized/restored).
  2. Second instanced should only utilize saved size, but not position and state. If it's not possible to cascade it, then just use random position. State, though, is debatable. Some might would prefer all instances maximized.
@bpasero

This comment has been minimized.

Copy link
Member

commented Apr 3, 2016

Allright, let me update the issue to reflect the discussion.

@regs01

This comment has been minimized.

Copy link

commented Jul 22, 2016

Most annoying thing about this problem is that it saves default window size every time you open second window. So basically those who are using multiple windows just stuck in a little window.

@bpasero bpasero removed their assignment Aug 17, 2016

@bpasero bpasero changed the title Preserve window size when restoring a window or opening new ones Preserve window size when restoring a maximized window Sep 3, 2016

@bpasero

This comment has been minimized.

Copy link
Member

commented May 25, 2017

Configuring window.newWindowDimensions helps in that case

@regs01

This comment has been minimized.

Copy link

commented May 25, 2017

window.newWindowDimensions helps to launch in previously stored size. But if it was maximized, then window size gets lost and resets to default.

@bpasero bpasero removed this from the Backlog milestone Nov 17, 2017

@tgdn

This comment has been minimized.

Copy link

commented Nov 21, 2017

Doing something similar to what electron-window-state does is probably the intended behaviour here

@adonig

This comment has been minimized.

Copy link

commented Dec 14, 2017

Here is a workaround for those who still suffer. Don't maximise the window by clicking the "maximise" button. Just drag the window borders to the borders of the screen so the window fills the whole screen. Thereafter it stores the size on close and launches maximised.

EDIT: Ok, sorry, This only works one time. The next time you start vscode it isn't maximised again.

EDIT2: Linux users can try this workaround.

@kocicmickey

This comment has been minimized.

Copy link

commented Jan 26, 2018

This bug accidentally saved my butt when I just started to use VS Code and accidentally made it full-screen. I couldn't figure out a way to exit full-screen mode, but when I shut down VS Code and restarted it, it was back to windowed. That helped me greatly because I can't find information on how to exit full screen using VS Code.

@rakkarage

This comment has been minimized.

Copy link

commented Feb 4, 2019

everyone on windows and linux is losing window size on maximize for 4 years?

@prasannavl

This comment has been minimized.

Copy link
Author

commented Feb 5, 2019

@kocicmickey - I probably wouldn't save full screen state anyway. So, even if this bug didn't exist, in the context of a text editor - I wouldn't design it with restoring full screen state unless explicitly configured so. But it's probably something to keep in mind whenever this thing gets fixed :)

@rakkarage - Yup. Probably, 2 years on Windows, and 2 years on Linux for me.

Unfortunately, while it clearly affects so many so widely, it's so minor a headache (resolvable through a 1 second effort), no one has taken it serious enough to step up to provide a PR yet (including myself, as I have just scripted it to a percent size of the screen so it doesn't affect me so much). That being said, I do hope that someone from the community steps up to fix it.

PS. As an aside, I think the whole window.newWindowDimensions is an unnecessary feature that the team gotten itself into, complicating startup things. I think redoing the startup workflow around fixing this would have kept things simple, and saved from yet another config property that probably wouldn't be need to be used in the first place in most cases, if this worked as indicated in the comments above. (The only real use case I'd see then, would be automation, which could be scripted anyway). So, overall I think vscode could have just done without window.newWindowDimensions and instead focusing that effort around this -- So far it has just led to more bugs and maintenance around that -- But now that this has been done, I'd assume fixing this too now probably involves having an "auto" option for it, which does the workflow as above, eventually turning this into the default option.

@rakkarage

This comment has been minimized.

Copy link

commented Mar 6, 2019

another workaround is to use devilspie2.lua or something to resize window when it starts

if (get_window_name()=="Visual Studio Code - Insiders") then unmaximize(); set_window_geometry(160, 90, 1600, 900); end

@bpasero bpasero self-assigned this Jul 1, 2019

@bpasero bpasero added this to the July 2019 milestone Jul 1, 2019

@bpasero

This comment has been minimized.

Copy link
Member

commented Jul 1, 2019

Electron 4 introduced a new method BrowserWindow.getNormalBounds() that allows to ask the window for its bounds in non-maximized state. I pushed a change to use this method on Linux and Windows such as when you restore the window, you will get those bounds returned.

@bpasero bpasero closed this in 0601c25 Jul 1, 2019

@regs01

This comment has been minimized.

Copy link

commented Jul 5, 2019

Did it go into June 2019 update?

@bpasero

This comment has been minimized.

Copy link
Member

commented Jul 6, 2019

No, July.
This issue has already been fixed in our insiders version but not yet released to the stable version. To benefit from the fix, you can give our preview releases a try from: https://code.visualstudio.com/insiders/

@bpasero

This comment has been minimized.

Copy link
Member

commented Jul 13, 2019

Verification: verify that the "normal" bounds of a window are persisted, via

  • be on Windows
  • position the window (not maximized) somewhere
  • maximize window
  • close
  • start
  • the window should opened maximized
  • now restore the window (click restore button in title)
  • the window should now have the size and position where you left it before

@sandy081 sandy081 added verified and removed verified labels Jul 30, 2019

@lramos15 lramos15 added the verified label Jul 30, 2019

@vscodebot vscodebot bot locked and limited conversation to collaborators Aug 15, 2019

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.