Windows Land on the Wrong Display

Check the arrangement before anything else

System Settings → Displays → Arrange. The rectangles representing your monitors must be dragged into the same relative positions as the physical hardware, including vertical offset when one screen sits higher than another.

If the model does not match reality, next-display and previous-display commands appear random — because the system's idea of which screen is to the right of which is not yours. This one check resolves most reports and takes two minutes.

• Drag each rectangle so left, right and height match your desk.
• The white menu bar strip marks the primary display; drag it to change which screen that is.
• Changing the primary display immediately reshuffles windows. That is expected.
• After a firmware or system update, verify it again — macOS occasionally reverts the choice.

Vertically stacked monitors and the ordering setting

Here is the setting almost nobody finds. Display order for next and previous commands is calculated left-to-right, line-by-line — like reading text. With monitors stacked vertically, or arranged in an L, that produces an order which feels arbitrary: you press next-display expecting the screen to your right and land on the one above.

The behaviour prior to v0.87 was a pure left-to-right ordering by horizontal coordinate, ignoring vertical position entirely. For stacked setups that is frequently the more intuitive model, and it can be restored:

# order displays purely by x coordinate, ignoring vertical position
defaults write com.knollsoft.Rectangle screensOrderedByX -int 1
killall Rectangle && open -a Rectangle

# back to the default line-by-line ordering
defaults delete com.knollsoft.Rectangle screensOrderedByX

Cycling versus moving

A related confusion. There is a setting for whether repeated left or right commands move the window to the adjacent display, and it interacts with the size-cycling behaviour. With display cycling enabled, pressing left-half twice sends the window to the next screen rather than cycling to a third; with it disabled, the second press changes the width instead.

This is governed by a single preference with five distinct modes, which is covered in full in the dedicated cycling guide. The short version for this problem:

# I want repeated left/right to move between displays
defaults write com.knollsoft.Rectangle subsequentExecutionMode -int 1
killall Rectangle && open -a Rectangle

Everything scatters when I undock

When a display disconnects, macOS must relocate its windows to a screen that still exists. When it reconnects, there is no record of where things were. This is standard system behaviour, not a fault in any window manager, and it cannot be prevented from outside.

The practical answer is to make rebuilding fast rather than to try to prevent the scatter. Bring each application forward, send it to the correct display with one keystroke, snap it into position with another. Five windows takes about ten seconds once it is habitual.

If you want saved multi-window arrangements restored in one command rather than window by window, that is a capability of the paid tier rather than the free build — an honest reason to consider it if you dock and undock several times a day.

The cursor stays behind

Sending a window to another display leaves the pointer where it was, so you act on the moved window and then have to find the cursor. There is a setting in the interface for moving the pointer along when crossing displays, and a hidden one that moves it with *any* shortcut:

defaults write com.knollsoft.Rectangle moveCursor -int 1
killall Rectangle && open -a Rectangle

On multi-display setups this is one of the highest-value hidden settings available, and it is entirely a matter of taste — some people find a jumping pointer disorienting. Try it for a day.

Displays with different scaling

A window moved between screens with different scaling factors will change apparent size, because the same fraction of a different pixel count is a different number of points. This is correct behaviour that looks like a bug: the window is still exactly half of the new screen.

Where it genuinely bites is applications with minimum window sizes. A window that cannot shrink below its minimum will not fit a quarter of a small display, so it is placed as close as possible and overflows. Nothing external can override an application's own size constraints; use a larger fraction on that screen.

Questions