Replies: 5 comments 4 replies
-
There's actually a WIP PR about this that I've left open because I haven't quite decided what I want to do (#191). To do this "properly", I would like to have the across displays action execute the same window action that put the window in its current state before the across displays command is executed (in your case, maximize). This would require a decent amount of effort and some adjustment in all the window calculations (ugh). However, I can see the case for just adding some one-off logic to determine if the window is maximized and then maximize it on the next display. I'll give it some more thought. |
Beta Was this translation helpful? Give feedback.
-
Hmmmm... yeah I mean on your point about doing one-off logic, I don't think it's too crazy in this case. Being "maximized" is a pretty particular state (especially Rectangle's "maximized" where there's a tiny margin around each boundary). As of right now it's hard to imagine that producing undesired behavior for many, but not sure. Something tangential I was thinking about -- when, for example, you're just using a macbook with no monitors and a window has state (e.g. centered, maximized), it always seems to be lost when you do plug in a monitor. Usually it will be the same size as it was in the smaller laptop's display, and will respect the x,y coordinates it had in the x,y display rather than if it was centered or not. It's a super common workflow I have to do where I had everything centered and/or maximized on my laptop, plug in a monitor and have to resize/recenter everything for the larger screen. |
Beta Was this translation helpful? Give feedback.
-
I want to second this ask! I'm having an odd issue where even after the display goes to black or the Mac wakes from sleep the windows all resize to my MacBook's screen size rather than my external monitor's and I would really love to not have to resize everything each time. |
Beta Was this translation helpful? Give feedback.
-
In 0.42, I added a quick initial first step on this, but it's not a solve-all fix for this scenario. It will maximize a window when moving to next/prev monitor only if the prior action was maximize. If you have 3 displays and move between them, then you can still end up with a scenario on the 2nd next/prev display execution where the window might not be maximized. There are additional changes in 0.42 that contain some building blocks for "reflowing" the windows, say in the event that you add/remove displays. However, again there is a significant amount of work to build it into an ideal solution for this issue. Side note, I've been migrating feature requests to GitHub discussions. Migrating this one now as well. |
Beta Was this translation helpful? Give feedback.
-
An option to disable this behaviour would be awesome – making it work just like Spectacle. This is really minor, but it's my biggest gripe with Rectangle. I've got this muscle memory workflow for moving something to my laptop screen, resizing to fill screen there (cmd+opt+F) and then moving it back to my (larger) external display to take a screenshot of the entire window or screen record it for demo purposes (and I do this super frequently). My workaround now is to move it to my laptop screen, cmd+opt+F, then resize down & then up again by one notch via ctrl+opt+shift+Left/Right, and then move it to the other/next display (ctrl+opt+cmd+Left/Right). |
Beta Was this translation helpful? Give feedback.
-
Just wanted to know if this was possible -- when moving a window that's maximized on a smaller display to a larger display with the
Maximize
shortcut, would it be possible to have that window also be maximized in the new larger display?e.g. I move a maximized Chrome window from my laptop display to my monitor display with
ctrl+opt+cmd+←
Beta Was this translation helpful? Give feedback.
All reactions