"Show windows from: Screen showing AltTab" should show window partially on-screen

[lwouis]

Specifically it happens to me when a window is maximized: I have a multi-monitor setup, and Alt-Tab is configured to show only windows on that screen. However, if a window overlaps one pixel onto the other monitor, it shows up in neither screen's Alt-Tab listing!

Originally posted by @thirtythreeforty in #603 (comment)

[lwouis]

@thirtythreeforty actually, we could use the center of the window to decide if it's on a screen, or we could be more permissive and show any window that has any part of it on that screen. Maybe that's better in the sense that better to show more than not enough, and also it kind of makes visual sense that if 40% of a window is on a screen, maybe it should be shown. Kind of a "the window is also on that screen mindset".

What do you think?

[lwouis]

By the way, I just checked and the current behavior is: if the top left corner is in the screen rectangle, then the window is "on screen". So you could have 1 px on the window on-screen, and if it's the top-left pixel, then the window would show in AltTab.

[thirtythreeforty]

The current behavior it's somewhat surprising. Sounds like my multi monitor setup made it easy for me to hit this, too.

I'd be alright with either of those behaviors. However, let me propose a third:

Does macOS have an API to let you query which display a window macOS thinks it's on? My intuition for where the window is is based on what the OS does with the menu bar etc. I think it's based on where the centroid is, but asking the OS directly would allow AltTab to exactly align with users' intuition.

[SoPat712]

@thirtythreeforty I think the NSScreen API should be able to do that? @lwouis can you confirm?

Edit: It might be NSApplication?

[lwouis]

Does macOS have an API to let you query which display a window macOS thinks it's on?

Not that I'm aware of.

My intuition for where the window is is based on what the OS does with the menu bar etc.

I don't understand what you mean here. Could you please go into details?

Current implementation is:

var screenFrameInQuartzCoordinates = screen.frame
screenFrameInQuartzCoordinates.origin.y = NSMaxY(NSScreen.screens[0].frame) - NSMaxY(screen.frame)
return screenFrameInQuartzCoordinates.contains(position)

Which reads "show if window's top-left corner is inside the screen's rectangle"

My proposed implementation is:

var screenFrameInQuartzCoordinates = screen.frame
screenFrameInQuartzCoordinates.origin.y = NSMaxY(NSScreen.screens[0].frame) - NSMaxY(screen.frame)
let windowRect = CGRect(origin: topLeftCorner, size: size)
return windowRect.intersects(screenFrameInQuartzCoordinates)

Which reads "show if the window's rectangle intersects with the screen's rectangle".

Apple doesn't provide an API that decides for us, so I suggest we go with this interpretation of "window is on screen X". If you have a better one, please share it here 👍

[thirtythreeforty]

That's a decent option; however, watch the following clip of me moving a wide Firefox window off the main display onto the laptop's smaller display:

Here's a synopsis of what happens:

• A window is only displayed on one display at a time. That display has a solid top menu bar when the window is active, and other displays' menu bars are dimmed.
• If I start dragging it onto another display, it appears on that display "ghosted" until...
• When the mouse crosses onto the other display, the window swaps to being "on" that display. That is, the mouse location, not any geometry of the window, determines which display the window will be on.
• When I drop the window, its dimmed/ghosted portion vanishes from other displays.

So, even if a window's centroid is on display 1, macOS might count it as being on display 2. Which would make your snippet select windows that aren't drawn on a display.

Apple doesn't provide an API that decides for us

Does NSWindow.screen not do this? (Disclaimer: I am not a macOS developer so I defer to you!)

[thirtythreeforty]

Does this behavior occur on your machine? Possibly, this "ghosting" happens because my displays have different pixel densities and it would be quite tricky to draw a window split over two such displays. (What should the application do? Downsample the portion that's on the low-res display?)

[lwouis]

So, even if a window's centroid is on display 1, macOS might count it as being on display 2. Which would make your snippet select windows that aren't drawn on a display.

I tested, and indeed it does. Mmm that's annoying. I'm not sure how to know if part of a window is displayed or not.

Does NSWindow.screen not do this? (Disclaimer: I am not a macOS developer so I defer to you!)

It doesn't. I'll have to do some research, and be creative. What's disturbing is that there is a public API on NSWindow, which says:

The value of this property is the screen where most of the window is on; it is nil when the window is offscreen.

That's not matching macOS definition though. It's not about how much of the window is on a given screen. It's about which screen the mouse was on when drag-and-drop is released. I guess it used to be different, and they didn't update the API docs.

Update: my bad, I forgot about the System Preference checkbox. I have it checked. I guess if it's unchecked, you can span a window on multiple displays. In that scenario, my proposal would work nicely, as you would see the window in AltTab on both displays, since it spans both.

Does this behavior occur on your machine? Possibly, this "ghosting" happens because my displays have different pixel densities and it would be quite tricky to draw a window split over two such displays. (What should the application do? Downsample the portion that's on the low-res display?)

I remember Apple touches on this interaction (i.e. drag-and-drop across screens) in their HIG. For example:

For example, if people drag your icon between displays with different resolutions, the icon’s appearance shouldn’t suddenly change.

[lwouis]

I'll have to test it out, but I think I've got a plan:

I'll use the Space the window is in, and the Space the screen is showing, to determine if the window should be shown in AltTab.

If you have unchecked the "Screens have separate Spaces" checkbox in System Preferences, the intersection I mentioned above will work. You will see the window on both screens, as you physically do with your eyes.

If you have checked the "Screens have separate Spaces" checkbox in System Preferences, I will use the information of which Space the window is on to decide with screen it is on, since each screen has a different Space, and the window will only be on 1 Space.

[thirtythreeforty]

Ah, I think you found the key point. I will play with that check box tomorrow on my Mac and see if it matches your description.

Edit: yep, you're exactly right. Matches my machine's behavior.

Thank you for thinking about this!

[lwouis]

@thirtythreeforty here is a local build where I implemented this ticket according to our conversation. Could you please test it and let me know if it works as expected? If it does it will be part of the next release 👍

[thirtythreeforty]

Yes! This works exactly as I expect. Thank you so much. (Sorry for delay, I was off for the holidays.)

There is one wrinkle, I am not certain if it is related to c1c8b9f: when I have "Show on: Screen including mouse" selected, the AltTab window does not appear if the display with the mouse is not active. (I have macOS's "separate screens on each display" enabled.)

[lwouis]

Hi @thirtythreeforty! I tested the scenario you describe, but everything works great on my machine. Multi-screen, window being on a certain screen, it all works for me.

Could you please re-test with this latest build I made locally?

If you face an issue, could you record your screen and show clearly your preferences (Controls and Appearance section).

I'm ready to release this, as soon as it works for you~

[lwouis]

Hey @thirtythreeforty could you please reply my message above? I'm waiting on your go to release this to everyone

[thirtythreeforty]

Apologies for being quiet. Yes, I can still reproduce with the build you posted. I've been trying to get a good video posted because it's difficult to see the behavior without keys:

Here's my settings:

[thirtythreeforty]

Oh I just figured out the culprit setting - Show windows from Active Space causes this.

[lwouis]

@thirtythreeforty I'm sorry I read many times and watched your gif many times, but still I don't understand what I should be looking at.

The ticket is about showing windows partially on screen. So my first question is: does this work, with the build I shared?

Then you mentioned a potential regression:

There is one wrinkle, I am not certain if it is related to c1c8b9f: when I have "Show on: Screen including mouse" selected, the AltTab window does not appear if the display with the mouse is not active. (I have macOS's "separate screens on each display" enabled.)

I don't reproduce the issue. Are you reproducing this issue with the build I shared? If yes, could you share the full setup like by filming from your phone maybe, so we see all screens in motion, and the full scenario where it doesn't work properly for you?

Thank you!

[thirtythreeforty]

Based on my experimentation I think the issue I describe is probably separate. The original issue description is indeed fixed. Thank you very much!

[lwouis]

I'm sorry, i couldn't understand the new issue you describe. Could you please write steps to reproduce and maybe a video? Maybe the best is to open a new ticket. There are guidelines on how to report a bug there that explain how best to do it 👍