Closed eshpakovsky closed 9 months ago
Thanks for reporting. I can't reproduce it. Could you include the logs for when this happens?
2023-09-07T00:18:12+03:00: AX sizing proposed: (2300.0, 1399.0), result: (2300.0, 1399.0) 2023-09-07T00:18:12+03:00: AX position proposed: (72.0, 33.0), result: (72.0, 33.0) 2023-09-07T00:18:12+03:00: AX sizing proposed: (2300.0, 1399.0), result: (2300.0, 1399.0) 2023-09-07T00:18:12+03:00: maximize | display: (64.0, 0.0, 2316.0, 1415.0), calculatedRect: (72.0, 33.0, 2300.0, 1399.0), resultRect: (72.0, 33.0, 2300.0, 1399.0), srcScreen: LG ULTRAFINE, destScreen: LG ULTRAFINE, resultScreen: LG ULTRAFINE
Hmmm, let me try this out on some other setups and get back to you.
Same issue here. I was thinking about adding another shortcut for maximizing window ignoring of stage manager safe area.
I was thinking about looking into this. Looks like the relevant function is probably StageUtil.isStageStripVisible
?
edit: I've been debugging a bit, and I just want to check that my understanding of this function is accurate; does this line by line explanation seem correct? If so, I think there may be a bug in determining whether windows in other spaces should be filtered or not; the value of infos.count
is consistently the number of total windows open on my system, not the windows open in the current space.
@matthewess thanks for looking into it. Indeed, you are on the right track with looking at isStageStripVisible
, and I don't see anything wrong in your notes there. I was testing on a different Mac, and was able to reproduce this, but it doesn't necessarily appear to be tied to different Spaces. I'll have to do some further debugging to get a better understanding of what's going on here.
@decodism, let me know if you want to take a look.
Started poking at this again. I've observed that closing windows in other spaces seems to affect the count of the infos array in the isStageStripVisible
method no matter what space is active when the function is running; e.g. I add a print(infos.count)
line after the filter, trigger it in one space and see 15
, switch spaces and close 2 windows, come back and try again, and see 13
consistently.
I'll admit that this "space blindness" doesn't seem to be the entirety of the issue, because in this scenario, I had only 8
actual windows open. That being said, I'm suspicious that maybe WindowUtil.getWindowList(all: true)
should only return windows in the current space, or else an additional check needs to be added after checking which NSScreen
is associated with a given window in order to determine which "space" is associated with that window, or at least whether it is associated with the current space.
In trying to figure out how to accomplish the above, I've hit sort of a dead-end. I can't find much specific language in the Apple docs about a primitive type that represents a "space". I did come across an isOnActiveSpace
property of NSWindow, but it seems like the current implementation is instead limited to the interface of Core Graphics. CG includes a different global called kCGWindowIsOnScreen
, but this does not seem like what we want here (although the sparse documentation makes it a bit hard to tell).
@matthewess, I still haven't had time to dive into this but will let you know when I do.
For troubleshooting what's going on, my suggestion is to print off the WindowInfo for all of the windows that the getWindowList call gives back. While doing that, you can filter out windows that are in the menu bar by looking at their size, and this should give you a better picture of what's being returned.
I don't recall this giving back windows on other spaces, and in my limited testing that I've done, the issue persists regardless of what's on another space or not, so I think this might not be our concern with this issue.
Edit: Ah, I realize I was thinking about this a little differently. The change put in by @decodism looks good from my testing, though, and it'll get rolled into the next release. If you want to test out his change, here's the unsigned build artifact: https://github.com/rxhanson/Rectangle/actions/runs/6411928629
I am commenting here today because I just updated to 0.74 and was really disappointed to see this was reverted. When I installed 0.73 I thought this was a feature because its super annoying when I have one window open, I maximize it and it takes the full screen; and then when I open another window I first maximize the new window and THEN have to go back to the old window and "maximize" it again so it shrinks in width and stage manager is visible again.
I understand how the behaviour in 0.73 might be annoying to people who work with single windows a lot (which kinda defeats the point of having stage manager on but different stokes for different folks I understand) but people who work with multiple windows (When I have to use a single window and simply full screen it using the green maximize button) "maximizing" two windows over and over gets old really fast.
I think the best way would be to make it an option, if thats possible.
I don't have plans to make this configurable, but am fine merging a PR that does. This would have to be a terminal command flag, as it wouldn't be something I would add to the UI.
[…] [Its] super annoying when I have one window open, I maximize it and it takes the full screen; and then when I open another window I first maximize the new window and THEN have to go back to the old window and "maximize" it again so it shrinks in width and stage manager is visible again.
I use Rechteck Pro. I completely agree with @aayushbhatia06 and would also very much like to have this option.
When Stage Manager is turned on and only 1 window opened Rectangle still make a gap for Stage Manager while MacOS hides SM.
macOS version: 13.5.1 Rectangle version: 0.70 (76) Logs if applicable (In Rectangle menu, hold option, "View Logging..."):