terminal
terminal copied to clipboard
microsoft
Opening a new terminal window does not restore the previous window's size and position on the screen
Windows Terminal version
1.13.10395.0
Windows build number
10.0.19044
Other Software
No response
Steps to reproduce
- Open Terminal
- Resize and reposition window
- Close window
- Open Terminal again
Expected Behavior
Terminal would open the window in the same position and size
Actual Behavior
The position and size are reset.
Note: I am not referring to session restore on start-up like you'd find in a web browser that can be enabled optionally. I'm referring to regular behaviour that people expect on desktop operating systems. And in particular, this makes it easier to use on smaller screens such as laptops.
Do you have window layout saving enabled? In Settings -> Startup -> "When Terminal starts" select the "Open windows from a previous session" option.
https://docs.microsoft.com/en-us/windows/terminal/customize-settings/startup#behavior-when-starting-a-new-terminal-session
Do you have window layout saving enabled? In Settings -> Startup -> "When Terminal starts" select the "Open windows from a previous session" option.
I don't want that, nor should I need that enabled to have this.
Edit: I even explicitly mentioned that option in my issue. No edits.
Alright so this is a new feature request - a setting to use the initialPosition, initialSize in state.json instead of the ones in the settings file. I suppose that could be a checkbox within the Launch Size expander. Ah, but then we've got the trick that we'd want one checkbox for "use previous position" and another for "use previous size". (admittedly, initialPosition isn't in the SUI yet, #9075). Then there's also the complicating factor that enabling "Open windows from a previous session" would spooky-action-at-a-distance check and disable those boxes.
So then it makes more sense to put this as another radio option in "When Terminal starts...". Or like, a checkbox under the "Open a tab with the default profile", that only ~reveals~enables itself when that radio button is selected? (hiding itself would be terrible discoverability)
An option doesn't really make sense to me. I don't really want anything complicated. I just want the default windowing behaviour I've come to expect from other apps. 🤷
We already have some other settings to control where the window is positioned and how big it is, so already we're off the rails of "other apps". I'm of the strong opinion that user preference is king - I'd love to give everyone as many knobs to control the Terminal as possible, to make it work exactly like they'd like.
I agree, it should just work its standard windows behaviour. Should respect the monitor it was on as well. Let people override if required but please follow principle of least surprises.
Discussion outcome: This probably needs a miniature spec (AKA: we agree on it in the issue, and check in a quick markdown document about it) as the team couldn't come to consensus on whether this is a firstWindowPreference or a launchPosition, and whether this is part of or not a part of the session restoration code.
Hah just came here to report this, I was thinking of two suggestions:
- Option to always spawn at a set of coordinates OR at the center of the screen
- Remember position properly
FWIW:
Option to always spawn at a set of coordinates OR at the center of the screen are already settings.
Unifying those two with bullet point 2 is the one that this issue is tracking - finding a good way of exposing that setting to the user both as a UI and in json is the hard part.
FWIW:
Option to always spawn at a set of coordinates OR at the center of the screen are already settings.
Unifying those two with bullet point 2 is the one that this issue is tracking - finding a good way of exposing that setting to the user both as a UI and in json is the hard part.
Oh my bad, sorry. I didn't see it in the UI options.
Any updates here?
I do use the subscribe button but I'm the author of this issue so I receive notifications by default. People have bumped other issues in Microsoft repos that were forgotten and that seemed to work for some of those issues. Doing so here isn't such a stretch.
Nope. We'll make sure to update this thread when there is. In the meantime, might I recommend the Subscribe button?
That way you'll be notified of any updates to this thread, without needlessly pinging everyone on this thread ☺️
As it stands, this issue remains at:
Discussion outcome: This probably needs a miniature spec (AKA: we agree on it in the issue, and check in a quick markdown document about it) as the team couldn't come to consensus on whether this is a
firstWindowPreferenceor alaunchPosition, and whether this is part of or not a part of the session restoration code.
If someone wants to sort out how exactly this should be implemented, we'd be more than happy to review a writeup ☺️
Some notes, march 2023:
- On my branch
- You delete tabLayout entirely (is null) -> right size & pos, but explodes
- you set tabLayout to [] -> Right size & pos, and uses the default profile
around 434abc247 (during #14825), this was actually almost trivially easy. We made the logic concerning the number of tabs persisted a bit more strict, but honestly, I think we could undo that easily. Commit 1b59eb923 was the one to enforce the "we must have tabs" thing
If someone wants to sort out how exactly this should be implemented, we'd be more than happy to review a writeup ☺️
FWIW, and when it comes to the implementation specifically, I believe this should use the GetWindowPlacement and SetWindowPlacement APIs. Those have been in use by other HWND applications for this purpose since forever.
