Terminal startup location partially off Desktop #4453

@DHowett-MSFT commented on GitHub (Oct 14, 2019):

Hey thanks! This is a /dupe of #1043

@DHowett-MSFT commented on GitHub (Oct 14, 2019): Hey thanks! This is a /dupe of #1043

claunia commented

@ghost commented on GitHub (Oct 14, 2019):

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

@ghost commented on GitHub (Oct 14, 2019): Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

claunia commented

@csylvain commented on GitHub (Oct 14, 2019):

notfixed by #2817
different than #1043 -- if i close Terminal in position where it is entirely on the Desktop, then start Terminal again and it's back to the partially off Desktop position again. i reported an issue because there does not seem to be a workaround.

@csylvain commented on GitHub (Oct 14, 2019): notfixed by #2817 different than #1043 -- if i close Terminal in position where it is entirely on the Desktop, then start Terminal again and it's back to the partially off Desktop position again. i reported an issue because there does not seem to be a workaround.

claunia commented

@DHowett-MSFT commented on GitHub (Oct 14, 2019):

#remember

@DHowett-MSFT commented on GitHub (Oct 14, 2019): #remember

claunia commented

@ghost commented on GitHub (Oct 15, 2019):

This issue has been marked as duplicate and has not had any activity for 1 day. It will be closed for housekeeping purposes.

@ghost commented on GitHub (Oct 15, 2019): This issue has been marked as duplicate and has not had any activity for **1 day**. It will be closed for housekeeping purposes.

claunia commented

@csylvain commented on GitHub (Oct 15, 2019):

hah hah bot. so tidy of you. but a HUMAN re-opened this issue. perhaps, bot, you should defer to carbon-based judgement?

@csylvain commented on GitHub (Oct 15, 2019): hah hah bot. so tidy of you. but a HUMAN re-opened this issue. perhaps, bot, you should defer to carbon-based judgement?

claunia commented

@DHowett-MSFT commented on GitHub (Oct 15, 2019):

My bad. I didn't take off the Resolution 😄

@DHowett-MSFT commented on GitHub (Oct 15, 2019): My bad. I didn't take off the Resolution :smile:

claunia commented

@DHowett-MSFT commented on GitHub (Apr 3, 2020):

Incoming notes from #4681

Environment
Windows build number: 1903  Build 18362.657
Windows Terminal version (if applicable):  0.9.433.0

Any other software?
Steps to reproduce

Change the settings to have a large number of lines, but a number that will fit on your screen, but only by an inch or so.

Start Windows Terminal repeatedly, noting that,eventually, the bottom of the terminal window goes beyond the bottom of the screen. This may take several attempts before the 'default' start position is too close to the bottom of the screen.

Expected behavior

I expect (hope?) that modern programs either save/restore the previous window size & position OR that the programs ensure that their entire window is visible when started.

If the window is larger than the screen, I would expect either

The top,left corner of the window to be at the top,left corner of the monitor

Optionally, the window size adjusted to fit on the screen automatically or, in the case of a terminal window, perhaps the font size adjusted downward until the window fits on the screen.

Actual behavior

I had my terminal configured to a rather large font and 50 lines at startup. This morning when I started it, the bottom 1/4 to 1/3 (I'm guessing) of the terminal window was below the bottom of the screen. There was more than enough space on screen ABOVE the terminal and it was easy enough to move, but the code should not require me to move it in order to see the whole window when it first loads!

@DHowett-MSFT commented on GitHub (Apr 3, 2020): Incoming notes from #4681 > # Environment > ``` > Windows build number: 1903 Build 18362.657 > Windows Terminal version (if applicable): 0.9.433.0 > > Any other software? > ``` > > # Steps to reproduce > 1. Change the settings to have a large number of lines, but a number that _will_ fit on your screen, but only by an inch or so. > 2. Start Windows Terminal repeatedly, noting that,eventually, the bottom of the terminal window goes beyond the bottom of the screen. This may take several attempts before the 'default' start position is too close to the bottom of the screen. > > # Expected behavior > I expect (hope?) that modern programs either save/restore the previous window size & position **OR** that the programs ensure that their entire window is visible when started. > > If the window is larger than the screen, I would expect either > > * The top,left corner of the window to be at the top,left corner of the monitor > * Optionally, the window size adjusted to fit on the screen automatically or, in the case of a terminal window, perhaps the font size adjusted downward until the window fits on the screen. > > # Actual behavior > I had my terminal configured to a rather large font and 50 lines at startup. This morning when I started it, the bottom 1/4 to 1/3 (I'm guessing) of the terminal window was below the bottom of the screen. There was more than enough space on screen _ABOVE_ the terminal and it was easy enough to move, but the code should not **require** me to move it in order to see the whole window when it first loads!

claunia commented

@dynahcatq commented on GitHub (Apr 28, 2020):

I'm looking at this issue and I have some questions:

the programs ensure that their entire window is visible when started <- Can a user overwrite this behavior? Suppose they set the initialPosition in settings.json and half of the window is not visible, should we adjust the window's position?
If the window is too large to fit the screen, should we adjust window to fit the screen or reposition it to top-left corner?

@dynahcatq commented on GitHub (Apr 28, 2020): I'm looking at this issue and I have some questions: 1. `the programs ensure that their entire window is visible when started` <- Can a user overwrite this behavior? Suppose they set the `initialPosition` in `settings.json` and half of the window is not visible, should we adjust the window's position? 2. If the window is too large to fit the screen, should we adjust window to fit the screen or reposition it to top-left corner?

claunia commented

@csylvain commented on GitHub (Apr 28, 2020):

related to this are the window coordinates acquired when using multiple
monitors. it's an infamous bug for a window to retain entirely off-screen
coordinates when the stretched mega-monitor area shrinks when one or more
monitors are disconnected.

@csylvain commented on GitHub (Apr 28, 2020): related to this are the window coordinates acquired when using multiple monitors. it's an infamous bug for a window to retain entirely off-screen coordinates when the stretched mega-monitor area shrinks when one or more monitors are disconnected.

claunia commented

@dynahcatq commented on GitHub (Apr 28, 2020):

@csylvain So when a user specified an initialPosition that would cause the off-screen coordinates, we should correct all 4 coordinates to be within the screen right?

@dynahcatq commented on GitHub (Apr 28, 2020): @csylvain So when a user specified an initialPosition that would cause the off-screen coordinates, we should correct all 4 coordinates to be within the screen right?

claunia commented

@csylvain commented on GitHub (Apr 28, 2020):

there's no nice way to retrieve a window with completely off-screen
coordinates.

yes, when faced with coordinates which cannot in any way been seen because
other monitors have vanished, it would be A Good Thing(tm) to reset the
window's coordinates where it can be seen again.

it is the point, after all, of creating a window, yes? to be seen
(somewhere, somehow) ?
(disappearing multi-monitors having been treated as One Big Monitor is
obviously a worst-case situation)

@csylvain commented on GitHub (Apr 28, 2020): there's no nice way to retrieve a window with completely off-screen coordinates. yes, when faced with coordinates which cannot in any way been seen because other monitors have vanished, it would be A Good Thing(tm) to reset the window's coordinates where it can be seen again. it is the point, after all, of creating a window, yes? to be seen (somewhere, somehow) ? (disappearing multi-monitors having been treated as One Big Monitor is obviously a worst-case situation)

claunia commented

@dynahcatq commented on GitHub (Apr 29, 2020):

@DHowett-MSFT Hi, after taking a look at the issue I would like to propose a fix to the issue.

Check the window's 4 corners (top-left, bottom-left, top-right, bottom-right) to determine if it is out of screen and reset top-left to (monitorInfo.rcWork.top, monitorInfo.rcWork.left), which normally will be (0, 0).
If the window's size should fit in the monitor, check if partial window is behind the taskbar (reset top-left coord if taskbar overlap).

What do you think?

@dynahcatq commented on GitHub (Apr 29, 2020): @DHowett-MSFT Hi, after taking a look at the issue I would like to propose a fix to the issue. 1. Check the window's 4 corners (top-left, bottom-left, top-right, bottom-right) to determine if it is out of screen and reset top-left to (`monitorInfo.rcWork.top`, `monitorInfo.rcWork.left`), which normally will be (0, 0). 2. If the window's size should fit in the monitor, check if partial window is behind the taskbar (reset top-left coord if taskbar overlap). What do you think?

claunia commented

@DHowett-MSFT commented on GitHub (Apr 29, 2020):

We'd definitely be willing to accept contributions that improve the art here 😄

@DHowett-MSFT commented on GitHub (Apr 29, 2020): We'd definitely be willing to accept contributions that improve the art here :smile:

claunia commented

@DHowett-MSFT commented on GitHub (Apr 29, 2020):

(We need to consider, of course, how folks may have multi-monitor layouts and the application could be at a negative position with regards to the primary display.)

@DHowett-MSFT commented on GitHub (Apr 29, 2020): (We need to consider, of course, how folks may have multi-monitor layouts and the application could be at a negative position with regards to the primary display.)

claunia commented

@dynahcatq commented on GitHub (Apr 29, 2020):

For the first part, I'm planning to use EnumDisplayMonitors to deal with multi-monitor layouts. So if four corners are in different monitor, it will be treated as visible and will not trigger the reset.

@dynahcatq commented on GitHub (Apr 29, 2020): For the first part, I'm planning to use `EnumDisplayMonitors` to deal with multi-monitor layouts. So if four corners are in different monitor, it will be treated as visible and will not trigger the reset.

claunia commented

@csylvain commented on GitHub (Apr 29, 2020):

a fair number of "regular folk" run a pair of monitors these days. the
invisible off-screen window is infamous in ham radio circles. i'd expect
document processors have encountered it, too.

yes, the coords could be far positive or negative relative to the remaining
monitors.

dynahcatq's description of how to return to coordinate sanity with
remaining monitor(s) sounds perfect.

@csylvain commented on GitHub (Apr 29, 2020): a fair number of "regular folk" run a pair of monitors these days. the invisible off-screen window is infamous in ham radio circles. i'd expect document processors have encountered it, too. yes, the coords could be far positive or negative relative to the remaining monitors. dynahcatq's description of how to return to coordinate sanity with remaining monitor(s) sounds perfect.

claunia commented