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

Quake Mode multi monitor setup #10274

Closed
samirbanjanovic opened this issue May 29, 2021 · 10 comments · Fixed by #10744
Closed

Quake Mode multi monitor setup #10274

samirbanjanovic opened this issue May 29, 2021 · 10 comments · Fixed by #10744
Assignees
Labels
Area-User Interface Issues pertaining to the user interface of the Console or Terminal Help Wanted We encourage anyone to jump in on these. Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-2 A description (P2) Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.

Comments

@samirbanjanovic
Copy link

I've been toying with quake mode and noticed some odd behaviors when running on multiple monitors, where one is on a vertical orientation. On first summon quake mode dropped down from my desired "main" monitor. Consecutive summons have it split between two monitors but never on a single monitor. I tried changing the monitor and desktop values of the command without luck.

In the attached image you can see that the window dropped down to my left most monitor (which is vertical).
It appears the drop down is tracing location of mouse relative to left|right of center in regards to the entire resolution of the combined screens (?).

If my mouse is towards left of center it will render on left most monitor, with the right edge meeting center of main screen.
image

If my mouse is to the right of center of main screen it renders on the right "half" of the resolution, with the left edge meeting center of main monitor.
image

Last interesting thing to happen is -- if my mouse is on the left edge of my left most screen it renders off screen.
image

@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels May 29, 2021
@TomaszGrzmilas
Copy link

In my case, I got two monitors. On first I have no Windows taskbar, on second I got Windows taskbar located at right monitor edge.

When I run Quake mode on monitor 2 it is looking ok:

image

But when I do Quake mode on monitor 1, Windows Terminal is having gap in place where the Windows taskbar is on second monitor:

image

@brentos99
Copy link

brentos99 commented Jun 3, 2021

I've been having some issues with the quake mode on multi monitors. (love this new feature btw)..

My setup is a 4k landscape monitor above the laptop and a hd portrait monitor next to the that. All 3 monitors have different resolutions and scaling factors.

When opening on the laptop screen it works perfectly, full width of the screen.
When opening on the 4k screen, it only goes to 3/4 width of the screen.
When Opening on the 1080, portrait screen, its width spills over to the 4k screen.

Sometimes it gets confused and doesn't know which is the active screen and opens in the previous window, other times it opens in random places on the screen (usually the middle)

There is also what feels like screen tear in the slide down effect.

Hope this helps in getting the bugs ironed out. If needed, I can provide screenshots.

Brent

@nico-abram
Copy link
Contributor

nico-abram commented Jun 28, 2021

I have two monitors, both have the task bar at the bottom, and both are using the regular orientation. However the quake mode terminal has the wrong width. It worked fine yesterday, I'm not sure what's wrong now:
imagen

EDIT: It is now fine after closing it with alt+f4 and opening it again

@zadjii-msft
Copy link
Member

Welp, that's weird. I've been using QM for a while with multi-mon, but never ran into anything like this. Maybe the vertical/horizontal orientation is important here. I'll stick this on 2.0 for now, but if anyone who's actually hitting this could help debug, that'd definitely be appreciated.

@zadjii-msft zadjii-msft added Area-User Interface Issues pertaining to the user interface of the Console or Terminal Help Wanted We encourage anyone to jump in on these. Issue-Bug It either shouldn't be doing this or needs an investigation. Product-Terminal The new Windows Terminal. labels Jul 7, 2021
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label Jul 7, 2021
@zadjii-msft zadjii-msft added Needs-Repro We can't figure out how to make this happen. Please help find a simplified repro. and removed Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting labels Jul 7, 2021
@zadjii-msft zadjii-msft added this to the Terminal v2.0 milestone Jul 7, 2021
@nico-abram
Copy link
Contributor

Ok I think I can reproduce my issue now. Like I said before, I have two monitors, both have the task bar at the bottom, and both are using the regular orientation.

  1. Open QM terminal with hotkey
  2. Hit winkey+shift+[left or right arrow key] to move it to the other monitor
  3. The terminal now has the wrong size in the second monitor
    imagen
  4. It is already wrong now, but if you move it back to the first screen (With either the QM terminal hotkey or winket+shift+[left or right arrow key] ), it is also wrong on the first monitor (It ends up like my screenshot in the comment above)

@zadjii-msft zadjii-msft removed the Needs-Repro We can't figure out how to make this happen. Please help find a simplified repro. label Jul 7, 2021
@zadjii-msft zadjii-msft added the Priority-2 A description (P2) label Jul 15, 2021
zadjii-msft added a commit that referenced this issue Jul 15, 2021
  I can't believe that we never did this. We'd just leave the quake
  window's size totally unchanged. That's so ridiculously dumb.
@ghost ghost added the In-PR This issue has a related PR label Jul 15, 2021
@ghost ghost removed the In-PR This issue has a related PR label Jul 15, 2021
@zadjii-msft zadjii-msft self-assigned this Jul 15, 2021
@zadjii-msft
Copy link
Member

notes before I leave for the weekend:

  • WM_WINDOWPOSCHANGING is probably not the right place to do this.
    • It gets called way too often, we don't need to try and enterQuakeMode that many times
    • For whatever reason, doing enterQuakeMode there does calculate the right size, but then the window still ends up at the wrong dimensions. Maybe this is getting followed up with a WM_SIZING or something.
  • Where is the right place to determine that we've moved? WM_MOVING? I suppose that might work

ghost pushed a commit that referenced this issue Jul 20, 2021
…tor (#10674)

## Summary of the Pull Request

When the quake window is moved to another monitor, re-evaluate it's size for that monitor.

## References
* megathread: #8888
* Similar, but not the same: #10274

## PR Checklist
* [x] Closes #10182
* [x] I work here
* [ ] Tests added/passed
* [n/a] Requires documentation to be updated

## Detailed Description of the Pull Request / Additional comments

We'll probably need to do this in a few more places, but I'm breaking PRs into small chunks for easier reviews.

## Validation Steps Performed

Summoned the window to a bunch of different resolutions. Where it would use the wrong size before, it no longer does.
zadjii-msft added a commit that referenced this issue Jul 20, 2021
@ghost ghost added the In-PR This issue has a related PR label Jul 21, 2021
@b-hayes
Copy link

b-hayes commented Jul 26, 2021

IM having a similar issue. I have horizontal screens layout but they're different resolutions and scaling. My secondary screen is 4k@150% scaling and my primary screen is 1440p. When the terminal opens on the secondary screen it doesn't go all the way across.

image

PS - Also really appreciate this quake console mode. I was doing it manually with AHK and then it wasn't working properly one day and realized you guys baked the feature in using the same hotkey 😅

@ghost ghost closed this as completed in #10744 Aug 2, 2021
ghost pushed a commit that referenced this issue Aug 2, 2021
## Summary of the Pull Request

<kbd>win+shift+arrows</kbd> can be used to move windows to adjacent monitors. When that happens, we'll new re-calculate the size of the window for the new monitor.

## References
* megathread: #8888

## PR Checklist
* [x] Closes #10274
* [x] I work here
* [ ] Tests added/passed
* [n/a] Requires documentation to be updated

## Detailed Description of the Pull Request / Additional comments

In `WM_WINDOWPOSCHANGING`, the OS says "hey, I'm about to do {something} to your window. You cool with that?". We handle that message by:
1. checking if the window was _moved_ as a part of this message
2. getting the monitor that the window will be moved onto
3. If that monitor is different than the monitor the window is currently on, then
  * calculate how big the quake window should be on that monitor
  * tell the OS that's where we'd like to be.

## Validation Steps Performed

* <kbd>win+shift+arrows</kbd> works right now
* normal quake summoning still works right
@ghost ghost added Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. and removed In-PR This issue has a related PR labels Aug 2, 2021
@b-hayes
Copy link

b-hayes commented Aug 8, 2021

Actually, is there any way to just turn this off? I want my own implementation back and WT won't let me use this keyboard shortcut for my AHK script anymore.

I thought it was cool but Quake mode is a hindrance I want it gone.

DHowett pushed a commit that referenced this issue Aug 25, 2021
…tor (#10674)

## Summary of the Pull Request

When the quake window is moved to another monitor, re-evaluate it's size for that monitor.

## References
* megathread: #8888
* Similar, but not the same: #10274

## PR Checklist
* [x] Closes #10182
* [x] I work here
* [ ] Tests added/passed
* [n/a] Requires documentation to be updated

## Detailed Description of the Pull Request / Additional comments

We'll probably need to do this in a few more places, but I'm breaking PRs into small chunks for easier reviews.

## Validation Steps Performed

Summoned the window to a bunch of different resolutions. Where it would use the wrong size before, it no longer does.
DHowett pushed a commit that referenced this issue Aug 25, 2021
## Summary of the Pull Request

<kbd>win+shift+arrows</kbd> can be used to move windows to adjacent monitors. When that happens, we'll new re-calculate the size of the window for the new monitor.

## References
* megathread: #8888

## PR Checklist
* [x] Closes #10274
* [x] I work here
* [ ] Tests added/passed
* [n/a] Requires documentation to be updated

## Detailed Description of the Pull Request / Additional comments

In `WM_WINDOWPOSCHANGING`, the OS says "hey, I'm about to do {something} to your window. You cool with that?". We handle that message by:
1. checking if the window was _moved_ as a part of this message
2. getting the monitor that the window will be moved onto
3. If that monitor is different than the monitor the window is currently on, then
  * calculate how big the quake window should be on that monitor
  * tell the OS that's where we'd like to be.

## Validation Steps Performed

* <kbd>win+shift+arrows</kbd> works right now
* normal quake summoning still works right
@ghost
Copy link

ghost commented Aug 31, 2021

🎉This issue was addressed in #10744, which has now been successfully released as Windows Terminal Preview v1.10.2383.0.:tada:

Handy links:

@ghost
Copy link

ghost commented Aug 31, 2021

🎉This issue was addressed in #10744, which has now been successfully released as Windows Terminal Preview v1.11.2421.0.:tada:

Handy links:

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-User Interface Issues pertaining to the user interface of the Console or Terminal Help Wanted We encourage anyone to jump in on these. Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-2 A description (P2) Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants