Restore window position when monitor topology changes #12625

@mws-rmain commented on GitHub (Feb 16, 2021):

Rather than tracking the last state for any/all 'monitors' ever connected, instead define 'context'. Most desktop users would have a single context (perhaps with multiple monitors, or maybe only one). Laptop users might have a 'standalone context' (laptop screen only), a 'home context' (laptop screen + home monitor), a 'work context' (laptop screen + work monitor), with layout (position+dimensions) stored for each 'context'.

@mws-rmain commented on GitHub (Feb 16, 2021): Rather than tracking the last state for any/all 'monitors' ever connected, instead define 'context'. Most desktop users would have a single context (perhaps with multiple monitors, or maybe only one). Laptop users might have a 'standalone context' (laptop screen only), a 'home context' (laptop screen + home monitor), a 'work context' (laptop screen + work monitor), with layout (position+dimensions) stored for each 'context'.

claunia commented

@DHowett commented on GitHub (Feb 16, 2021):

I feel like this is win32/user32’s responsibility, isn’t it? Any logic we implement here will directly conflict with anything they do to solve topology change issues down the line... :/

@DHowett commented on GitHub (Feb 16, 2021): I feel like this is win32/user32’s responsibility, isn’t it? Any logic we implement here will directly conflict with anything they do to solve topology change issues down the line... :/

claunia commented

@mws-rmain commented on GitHub (Feb 16, 2021):

Could you expand on what '...topology change issues..' you are referring to, and how you believe logic being discussed might 'conflict'?
What's discussed so far is pretty well contained: preserving & restoring window position & size on already encountered monitor combinations. If a NEW monitor is encountered (for instance, the laptop user plugs into a TV screen in a hotel room as a secondary monitor), the user could be prompted to label the new context for save/restore - if they choose not to label it, it will not persist; this combination is just treated as 'new' again the next time it is encountered.

Of course you could leave it up to the user to restore the operating state, but this gets tedious very quickly, and could (/should?) be easy to automate.

@mws-rmain commented on GitHub (Feb 16, 2021): Could you expand on what '...topology change issues..' you are referring to, and how you believe logic being discussed might 'conflict'? What's discussed so far is pretty well contained: preserving & restoring window position & size on already encountered monitor combinations. If a NEW monitor is encountered (for instance, the laptop user plugs into a TV screen in a hotel room as a secondary monitor), the user could be prompted to label the new context for save/restore - if they choose not to label it, it will not persist; this combination is just treated as 'new' again the next time it is encountered. Of course you could leave it up to the user to restore the operating state, but this gets tedious very quickly, and could (/should?) be easy to automate.

claunia commented

@mws-rmain commented on GitHub (Feb 16, 2021):

RE: 'context' vs. remembering monitors.
"If I disconnect my big monitor again, the Terminal should come back to the last position on my notebook's screen." Operating this way would ASSUME the user wanted the terminal open on 'the big screen' whenever it was plugged in. Users may well have some other app that is much more demanding of screen space that they want on 'the big screen', and want the terminal to remain on the laptop screen. This is the reason I'd suggest 'context' as a more generic concept.

@mws-rmain commented on GitHub (Feb 16, 2021): RE: 'context' vs. remembering monitors. "If I disconnect my big monitor again, the Terminal should come back to the last position on my notebook's screen." Operating this way would ASSUME the user wanted the terminal open on 'the big screen' whenever it was plugged in. Users may well have some other app that is much more demanding of screen space that they want on 'the big screen', and want the terminal to remain on the laptop screen. This is the reason I'd suggest 'context' as a more generic concept.

claunia commented

@clounie commented on GitHub (Feb 16, 2021):

Could you expand on what '...topology change issues..' you are referring to, and how you believe logic being discussed might 'conflict'?
What's discussed so far is pretty well contained: preserving & restoring window position & size on already encountered monitor combinations. If a NEW monitor is encountered (for instance, the laptop user plugs into a TV screen in a hotel room as a secondary monitor), the user could be prompted to label the new context for save/restore - if they choose not to label it, it will not persist; this combination is just treated as 'new' again the next time it is encountered.

From a user's perspective...why are you making me label things by default? That's annoying. Just be smart enough to remember the combinations. (laptop + 4k, laptop + 2k wide..etc.) The need to label different contexts feels like a 1% scenario.

Also, remembering combinations ^ isn't exactly resource-intensive. So forcing labeling to me seems (1) annoying as a user (2) over-optimizing - in addition to @DHowett 's comment above about win32/user32.

@clounie commented on GitHub (Feb 16, 2021): > Could you expand on what '...topology change issues..' you are referring to, and how you believe logic being discussed might 'conflict'? > What's discussed so far is pretty well contained: preserving & restoring window position & size on already encountered monitor combinations. If a NEW monitor is encountered (for instance, the laptop user plugs into a TV screen in a hotel room as a secondary monitor), the user could be prompted to label the new context for save/restore - if they choose not to label it, it will not persist; this combination is just treated as 'new' again the next time it is encountered. From a user's perspective...why are you making me label things by default? That's annoying. Just be smart enough to remember the combinations. (laptop + 4k, laptop + 2k wide..etc.) The need to label different contexts feels like a 1% scenario. Also, remembering combinations ^ isn't exactly resource-intensive. So forcing labeling to me seems (1) annoying as a user (2) over-optimizing - in addition to @DHowett 's comment above about win32/user32.

claunia commented

@mws-rmain commented on GitHub (Feb 16, 2021):

You're probably right. The number of combinations a given installation will experience is likely to be small. The benefit of labelling the combinations would be apparent when trying to purge / maintain numerous combinations - and that's likely to be a 1% scenario. As you say, it's not resource-intensive, so perhaps maintenance is irrelevant.

I'm still interested in what might be details of the '...direct conflict with topology change issues...' referred to by @DHowett (?)

@mws-rmain commented on GitHub (Feb 16, 2021): You're probably right. The number of combinations a given installation will experience is likely to be small. The benefit of labelling the combinations would be apparent when trying to purge / maintain numerous combinations - and that's likely to be a 1% scenario. As you say, it's not resource-intensive, so perhaps maintenance is irrelevant. I'm still interested in what might be details of the '...direct conflict with topology change issues...' referred to by **@DHowett** (?)

claunia commented

@DHowett commented on GitHub (Feb 16, 2021):

Sorry, what I mean is:

I don't want to add code to detect monitor topologies and save/restore our layout when they change, because I think that if we do that we're going to become a thorn in the side for the folks who actually own the window manager if they do the same thing (thereby fixing the issue for everyone on Windows, not just Terminal). Every bit of manual window positioning we do that is in response to complicated messages (like "the DPI is about to change, are you ready?") has proven to be a liability given time's inexorable march forward.

😄

@DHowett commented on GitHub (Feb 16, 2021): Sorry, what I mean is: I don't want to add code to detect monitor topologies and save/restore our layout when they change, because I think that if we do that we're going to become a thorn in the side for the folks who actually own the window manager if they _do the same thing_ (thereby fixing the issue for everyone on Windows, not just Terminal). Every bit of manual window positioning we do that is in response to complicated messages (like "the DPI is about to change, are you ready?") has proven to be a liability given time's inexorable march forward. :smile:

claunia commented

@mws-rmain commented on GitHub (Feb 17, 2021):

I think I follow the issue you're raising, but:

This is under windows, so isn't windows the only window manager in play here? It's not like MS terminal is running under linux where there are any number of different window managers, each with a different approach. I'm certainly not current, nor a 'guru' in MS Windows app development, but is an app that remembers it's location & size (/monitor where multiple are concerned) causing allot of grief to the MS Windows OS (/window manager)? Even if the OS (/window manager) was trying to save & recall windows location & size (/monitor) for every app, if the app were doing the same, wouldn't it just override whatever defaults the OS had set? When the app closes, both the OS & the app settings would be updated to whatever is current, so I don't see there's much of a 'conflict' there, although you could certainly make a case for it being less than efficient (ideally this 'feature' would be in the OS (/window manager) so it's behavior would be consistent across ALL apps). Unfortunately, I don't think windows is currently doing this - certainly not to the 'multiple context' level where different configurations of screens come into play.
I don't believe processing of DPI change events is not really applicable to what we're discussing. I would suggest that the user changing resolution on his screen, or if the user drags the MS Terminal window from one monitor to another, then the DPI change will need to be addressed, and it could absolutely get complicated, especially if the window spans monitors with different resolutions. But these issues exist regardless of whether the initial window location & size (/monitor) is saved & restored, or not.

For my purposes, the title of this thread would be more accurately described as 'Restore initial window position, size & monitor on app startup, and save these parameters on app shutdown'.

Personally I use windows terminal in conjunction with other applications when I am setting up a test workspace. Setting up the workspace is tedious & repetitive, BECAUSE windows doesn't remember where all the apps were (/should be) placed. I don't have the option of making simple suggestions like 'It would be great if your app could save & restore window location & size (/monitor).' for most (/almost all) of the apps I use, but in the case of MS Terminal, I have this opportunity. IF I had the opportunity to suggest MS Windows could do a better job of this, I would certainly pursue it. For now, I'll take what baby steps I can. Maybe MS Terminal handling of this feature can serve as an example to other apps - maybe eventually to the OS (/window manager).

@mws-rmain commented on GitHub (Feb 17, 2021): I think I follow the issue you're raising, but: 1) This is under windows, so isn't windows the only window manager in play here? It's not like MS terminal is running under linux where there are any number of different window managers, each with a different approach. I'm certainly not current, nor a 'guru' in MS Windows app development, but is an app that remembers it's location & size (/monitor where multiple are concerned) causing allot of grief to the MS Windows OS (/window manager)? Even if the OS (/window manager) was trying to save & recall windows location & size (/monitor) for every app, if the app were doing the same, wouldn't it just override whatever defaults the OS had set? When the app closes, both the OS & the app settings would be updated to whatever is current, so I don't see there's much of a 'conflict' there, although you could certainly make a case for it being less than efficient (ideally this 'feature' would be in the OS (/window manager) so it's behavior would be _consistent_ across ALL apps). Unfortunately, I don't think windows is currently doing this - certainly not to the 'multiple context' level where different configurations of screens come into play. 2) I don't believe processing of DPI change events is not really applicable to what we're discussing. I would suggest that the user changing resolution on his screen, or if the user drags the MS Terminal window from one monitor to another, then the DPI change will need to be addressed, and it could _absolutely_ get complicated, especially if the window spans monitors with different resolutions. But these issues exist _regardless_ of whether the initial window location & size (/monitor) is saved & restored, or not. For my purposes, the title of this thread would be more accurately described as 'Restore _initial_ window position, size & monitor on app startup, and save these parameters on app shutdown'. Personally I use windows terminal in conjunction with other applications when I am setting up a test workspace. Setting up the workspace is tedious & repetitive, _BECAUSE_ windows doesn't remember where all the apps were (/should be) placed. I don't have the option of making simple suggestions like 'It would be great if your app could save & restore window location & size (/monitor).' for most (/almost all) of the apps I use, but in the case of MS Terminal, I have this opportunity. IF I had the opportunity to suggest MS Windows could do a better job of this, I would certainly pursue it. For now, I'll take what baby steps I can. Maybe MS Terminal handling of this feature can serve as an example to _other_ apps - maybe eventually to the OS (/window manager).

claunia commented

@Poopooracoocoo commented on GitHub (Feb 17, 2021):

Windows should definitely fix this. It'd be really weird if Terminal tried to fix this. Especially as it's from Microsoft. There's a uh certain irony with that.

@Poopooracoocoo commented on GitHub (Feb 17, 2021): Windows should definitely fix this. It'd be really weird if Terminal tried to fix this. Especially as it's from Microsoft. There's a uh certain irony with that.

claunia commented

@ansromanov commented on GitHub (Feb 17, 2021):

I think using PowerToys FancyZones (https://docs.microsoft.com/en-us/windows/powertoys/fancyzones) could be the possible solution to this issue. But looks like FancyZones itself struggles to keep layout settings аfter switching monitor configuration (https://github.com/microsoft/PowerToys/issues/9355), and I do not have a Windows laptop at the moment to check exact behavior.

@ansromanov commented on GitHub (Feb 17, 2021): I think using PowerToys FancyZones (https://docs.microsoft.com/en-us/windows/powertoys/fancyzones) could be the possible solution to this issue. But looks like FancyZones itself struggles to keep layout settings аfter switching monitor configuration (https://github.com/microsoft/PowerToys/issues/9355), and I do not have a Windows laptop at the moment to check exact behavior.

claunia commented

@brianroadifer commented on GitHub (Jul 3, 2021):

I think this could be a non-issue now seeing that the Windows team added this sort of feature system wide for Windows 11, see event livestream at 13:47 and could back port it to a later Windows 10 update.

@brianroadifer commented on GitHub (Jul 3, 2021): I think this could be a non-issue now seeing that the Windows team added this sort of feature system wide for Windows 11, [see event livestream at 13:47](https://www.microsoft.com/en-us/windows/event) and could back port it to a later Windows 10 update.

claunia commented

@zeh commented on GitHub (Jul 3, 2021):

I think using PowerToys FancyZones (https://docs.microsoft.com/en-us/windows/powertoys/fancyzones) could be the possible solution to this issue. But looks like FancyZones itself struggles to keep layout settings аfter switching monitor configuration (microsoft/PowerToys#9355), and I do not have a Windows laptop at the moment to check exact behavior.

For all it's worth, I use FancyZones for all my resizing (including Terminal) in a multiple monitor configuration and it has been working fine. I personally haven't ran into the situation described in that issue, even though I'm constantly disconnecting stuff.

That said, having Terminal restore itself would be better. Having to find out where the terminal is and do Windows + Left + Down + Down all the time anything changes in my topology, or I run the application, can get repetitive pretty fast.

@zeh commented on GitHub (Jul 3, 2021): > I think using PowerToys FancyZones (https://docs.microsoft.com/en-us/windows/powertoys/fancyzones) could be the possible solution to this issue. But looks like FancyZones itself struggles to keep layout settings аfter switching monitor configuration ([microsoft/PowerToys#9355](https://github.com/microsoft/PowerToys/issues/9355)), and I do not have a Windows laptop at the moment to check exact behavior. For all it's worth, I use FancyZones for all my resizing (including Terminal) in a multiple monitor configuration and it has been working fine. I personally haven't ran into the situation described in that issue, even though I'm constantly disconnecting stuff. That said, having Terminal restore itself would be better. Having to find out where the terminal is and do Windows + Left + Down + Down all the time anything changes in my topology, or I run the application, can get repetitive pretty fast.

claunia commented