Move window to display where cursor

Settings → Behavior → Across Display Settings: Gets new option + hint

☑︎ Move window to display where cursor

All move commands will move the focused window to its target position on the display where the cursor currently resides.

Operation

Focus the window you want to move.
Optional: Move the cursor (=mouse pointer) to another display where the window shall be positioned on.
- Note: If you keep your cursor where it is, then the window will simply move within the same display.
Trigger window move command (e.g. "Left" (⌃ ⌥ ←) or "Bottom" (⌃ ⌥ ↓) )

Usability Rationale & Best Practise

For smooth & efficient tile based window positioning in a multi display setup this workflow is superb!
Divvy, my current window manager, has this behavior hardcoded, and it served me really well over the years.
- Sadly it's an Intel binary, no longer maintained, and will not run anymore on macOS 28.

The current workarounds for step 2 with Rectangle

Move window to other display by dragging

OR

Trigger shortcut for "Next Display".
- Note: On a 2 monitor setup this effectively is "Toggle Display", so this itself needs no further thought. On a 3 monitor setup if you know their index order, you can reach any target by "Next Display" or "Previous Display". Already more mental load. Mishaps happen for sure. With a 4 display setup it becomes bloated multi step operation guaranteed.

Any or these workarounds: Too much mental load!

Whereas with the proposed workflow it's smooth and fast.
Your eyes and trackpad move in concert to your intended display.
There you press your intended position hotkey and are done in one pass.

Compatibility & Consistency

How does Move window to display where cursor interact with existing options?

1) `Move cursor along with window across displays`

When the commands Previous Display or Next Display get executed, then Move cursor along with window across displays takes precedence over Move window to display where cursor.

When any tiling commands (e.g. "Left" (⌃ ⌥ ←) or "Bottom" (⌃ ⌥ ↓) ) get executed, then Move window to display where cursor takes precedence over Move cursor along with window across displays.

✅ Scenario 1a

Move cursor along with window across displays: ON
Move window to display where cursor: OFF
This is the status quo. Works.

✅ Scenario 1b

Move cursor along with window across displays: OFF
Move window to display where cursor: ON
Works well too, best practice: Divvy

✅ Scenarios 1c

Move window to display where cursor: ON
Move cursor along with window across displays: ON

Usually you utilize Move window to display where cursor.

But in rare situations you want hands on keyboard-only.
Need to move window to next screen.
But this time without moving a hand to trackpad/mouse
And want the cursor close, thereafter
Seems unlikely. But works conflict free in numerous variations, for those who need it (occasionally / as an amendment).

✅ Scenario 1c1

Start
- Screen 1: Focused window
- Screen 2: ---
- Screen 3: Cursor
Command "Next Display"
- Screen 1: ---
- Screen 2: Focused window + Cursor
- Screen 3: ---
Explanation:
- Screen 2 was next in index, thus window moved there
- Cursor moved to screen 2 because of Move cursor along with window across displays
- Move cursor along with window across displays takes precedence when triggered by the "Prev/Next Display" command

✅ Scenario 1c2

Start
- Screen 1: Focused window + Cursor
- Screen 2: ---
Command "Next Display"
- Screen 1: ---
- Screen 2: Focused window + Cursor
Explanation
- Screen 2 was next in index, thus window moved there
- Cursor moved to screen 2 because of Move cursor along with window across displays
- Move cursor along with window across displays takes precedence when triggered by the "Prev/Next Display" command

2) `Repeated commands` which involve display cycling

Settings → Behavior → Repeated commands: Options which involve display cycling

Cycle through displays
Move to adjacent display on left or right
Move to adjacent on left/right, or cycle size on side

Governance:

A combination of a tiling command (e.g. "Left" ⌃ ⌥ ←) with Move window to display where cursor ON results the tile moving to a new screen.

Then triggering the same tiling command cannot be reasonable be considered a repetition!
You wanted it "Left on that new screen" where it anyhow needs to sit itself potentially into a different screen resolution and/or aspect ratio.
Only another invocation of the very same tile command is then a user intent for a repeat command.

✅ Scenario 2a

Move window to display where cursor: ON
Repeated commands: Cycle sizes on side actions
Start
- Screen 1: Focused window Maximized + Cursor
- Screen 2: ---
- Screen 3: ---
Command "Left" ⌃ ⌥ ←
- Screen 1: Focused window Left + Cursor
- Screen 2: ---
- Screen 3: ---
User moves cursor to screen 3 → All keyboard command invocation counters get reset to 0
- Screen 1: Focused window Left
- Screen 2: ---
- Screen 3: Cursor
Command "Left" ⌃ ⌥ ← → Considered the first invocation (on the new screen!)
- Screen 1: ---
- Screen 2: ---
- Screen 3: Focused window Left + Cursor
Command "Left" ⌃ ⌥ ← →
- Screen 1: ---
- Screen 2: ---
- Screen 3: Focused window Left now grown a bit towards the right + Cursor

✅ Scenario 2b

Move window to display where cursor: ON
Repeated commands: Any option which moves the tile to another screen
When this constellation arises, both options get this extra hint text below them:

The option Move window to display where cursor is ignored when Repeated commands is set to any of the options which effectively moves the window to another screen.

Makes sense to me. I don't have the bandwidth to add this in myself at the moment, but would welcome a good pull request for it.

Glad that the feature makes sense to you as the project owner.
I'm a UX designer by trade. The best I could try regarding implementation and PR is:

a) Get a fellow developer interested in it — Anyone interested?
- What I could offer: Finishing spec together (if open points get identified) and then testing.
b) Try to implement this feature by aid of a coding agent.
- b1) Would this be permitted in this project?
- b2) is the repo set up in a way that agents find their way and can adhere to repo standards?
- b3) Any recommendation which model and mode/cognition-strength to use? Any typical pitfalls?

Before I go further, could you please aid the conceptual/analytical part by answering the following:

a) Was my assessment of Compatibility & Consistency correct?
b) Are there any other behaviors and/or options which would interfere, or other interplay/feats which possibly needs adaptation?

@porg

@porg I've opened a PR for this: #1913

It shows the "Move window to display where cursor is" setting under Across Display Settings. When it's on, commands move the window to the display under the cursor. It also fixes the repeat problem: if you move the cursor to another display, the next press starts fresh there instead of continuing on the old display. If the cursor stays put, repeats behave the same as with the setting off.

I tested it on two monitors with halves and thirds, and all tests pass. One caveat: my Mac can't run Xcode 27, so I built it with Xcode 26.0.1 plus a few local-only changes to get it compiling (not included in the PR). Could you or someone with Xcode 27 build it and give it a quick try on a multi-display setup? Thanks!

Move window to the display under the cursor (rxhanson#1908)

@Kiizon

@Kiizon thanks for your implementation! So quick! Glad that this issue caught the momentum!

@rxhanson & @Kiizon & others:

I never ever compiled an Xcode app (except xcode cli tools in brew). Until I'd have that Xcode dev env up & running, also with Swift Package Manager to install Sparkle and MASShortcut, surely some time would pass by.
To not waste the momentum: Could someone make a Apple Silicon (ARM64) build for macOS 15 as well as macOS 27 (with a proper developer signature maybe)? I could test those builds with a multi screen setup and share my test findings here then.

I'm still working my way through the queue of pull requests, so it'll still be a bit before I get to this. Although you were looking for something signed, if you want to try something sooner you can try the unsigned build from GitHub actions: https://github.com/rxhanson/Rectangle/actions/runs/38465694777/artifacts/11864920882

@rxhanson

@rxhanson thanks for pointing me to the build artifact!

I'm testing various scenarios under various option combinations.
Will report back with my findings.

Build from 2026-10-14 01:51 UTC on macOS 15 (Apple Silicon).

TL;DR

👍 New feature works as envisioned. In my personal configuration X it works perfect, no side effects whatsoever.
🧐 As an experienced UX designer and responsible tester/contributor needing to balance needs/configurations of all users, I conducted intensive testing, analysis & writeup (7h) how to make this feature addition beneficial on its own as well as being aligned with existing functionality and interplay. In configurations A, B, C I found some minor flaws which could get optimized.

My testing feedback

✅ = Existing and/or new feature and/or their interplay works as expected
❌ = Bug/Misbehavior
❗️ = Expected fix
❓ = Behavior to be discussed (irritation or disruption)
💡 = Idea how to improve or a genuinely new idea
🆗 = Okay as in "workaround exists" or "good enough"

My test setup

Internal Display: MacBook Air M3 15.3 at 1440x900 software pixels, retina resolution, 2880x1864 native resolution at 224 PPI. I don't use the extra screen area left and right of the notch.
External Display: 24'' at 1920x1080 hardware pixels (@1x standard resolution).
No third display: For final testing we may need this. But for round 1 of testing I got enough findings from testing with 2 displays.

Screen Arrangement: Both physically and in System Settings → Displays → Arrangement:

External 24'' screen elevated on top.
Internal 15.3'' display immediately below.

Terminology

Tiling command: A keystroke which repositions the focused window to a particular tile, such as Left (Half) or Top Right (Quarter) or Top Center Sixth
Relative move command: Such as Next Display or Previous Display
Resizing command: Such as Larger or Smaller or Larger Width or Smaller Width

UX assumptions & Terminology

Mouse/gaze first operation paradigm — When using Move window to display where cursor.
- User moves cursor plus gaze to new display
  - Intent starts: "I want to move my current window to that screen, but not clear where exactly".
  - Intent clarifies: "Now that my gaze reached the new screen and I captured the window situation there, I now know clearly where I want to position my window of interest, that still sits at the origin screen."
- Then moves window by keystroke to intended tiling position.
- And then resumes moving cursor naturally without disruption.
Keyboard first operation paradigm — When using Move cursor along with window across displays.
- User has screen/tile position intent first (mental image before it materializes).
- Gaze follows window to mentally designated screen and target tile position.
- There finds cursor, moves on.
Mixed operation paradigms
- Users who have activated both options Move cursor along with window across displays and Move window to display where cursor activated and who use relative move commands such as Next Display.
- Realistic because they may apply one paradigm for one situation and the other paradigm for another situation or maybe even mixed paradigms at some times, e.g.:
  - Mouse/gaze first for visual work when juggling between windows of a video editor, bitmap graphics editor and vector graphics editor.
  - Keyboard first for text focused work, like a coder working in multiple terminal windows and a text editor in parallel.
  - Mixed operation when doing both terminal + video/graphics editing at the same time.

Options that I ignored for interplay and at which values I left them

Behavior
- Repeated commands
  - Do nothing
    - If in use then no cross effects are to be expected.
    - When chosen, no harm was observed either.
    - Was not used in any of the complex interplay test scenarios stated below.
  - Move to adjacent display on left or right
  - Move to adjacent on left/right, or cycle size on side
    - For the following both options this applies:
      - Only test-able in true side by side display setups. Would exploding test scope.
      - I roughly tested it with setting my arrangement to internal left, external right, and superficially it seemed to behave right. But no full tests.
- Across Display Settings
  - Preserve maximize state when moving across displays
  - Center windows when moving across displays
    - For both options I report the following:
      - Continued working with keyboard first operation.
      - In mouse first you cannot make meaningful use of it. No harm was observed either.
      - I left it OFF throughout all the complex interplay test scenarios stated below.

Options that I inspected on their own and in terms of interplay

Behavior
- Repeated commands
  - Cycle through displays
  - Cycle sizes on side actions
  - Cycle positions on quadrants, cycle sizes on side
- Across Display Settings
  - Move window to display where cursor
  - Move cursor along with window across displays

Configuration X

Repeated commands: Do nothing or Cycle sizes on side actions
Across Display Settings
- ☑️ Move window to display where cursor
- 🔲 Move cursor along with window across displays

Observations

✅ My personally preferred setup. Perfect for my needs.
✅ No side effects whatsoever.

Configuration A

Repeated commands: Cycle sizes on side actions or Cycle positions on quadrants, cycle sizes on side
Across Display Settings
- ☑️ Move window to display where cursor
- ☑️ Move cursor along with window across displays

Scenario

Focus window
Keep mouse on same screen
Press tiling keystroke (tested: half, quarter, sixth)

✅ Window lands at tiling position
✅ Cursor coordinates remain unchanged
- Correct considers ☑️ Move cursor along with window across displays which does not kick in when focused window and cursor are on the same screen.

Press same tiling keystroke again

✅ Window cycles according to Repeated commands directive.

Move mouse to other screen
Press tiling keystroke

✅ Window lands at tiling position on screen where the cursor resides
- Correct considers the newly introduced option ☑️ Move window to display where cursor.
Cursor gets centered within repositioned window
- ❓ Disrupts the Mouse/gaze first operation paradigm a bit.
- 🆗 Simply disable Move cursor along with window across displays if not using a "Keyboard first" operation paradigm.
- 💡 We deem Mixed operation legitimate and accordingly optimize it further:
  - Move cursor along with window across displays gets this hint (and behavioral change in code)
  - Does not apply when a window moves to another display due to "Move window to display where cursor".

Press same tiling keystroke again

✅ Window remains on same screen it has arrived at in the recent step.
✅ Window remains anchored but resizes through its defined sizes.
These are the correct outcomes of options Move window to display where cursor and Repeated commands → Cycle sizes on side actions.

Configuration B

Repeated commands: Cycle through displays
Across Display Settings
- ☑️ Move window to display where cursor
- 🔲 Move cursor along with window across displays

Scenario

Focused window somewhere random on grid
Cursor on same screen
Press tiling keystroke (e.g. Top Left)

✅ Window moves to target tile on same screen.

Press same tiling keystroke again (multiple times)

✅ This and every further keystroke cycles between displays without ever being stuck of off.

Somewhen after a repeat cycle:

a) Cursor is on same display as focused window.
b) Press a different tiling keystroke (e.g. Top Right)
- ✅ Window moves to target tile on same screen.
c) Press that tiling keystroke again (e.g. Top Right) (multiple times)
- ✅ This and every further keystroke cycles between displays without ever being stuck of off.

Somewhen after a repeat cycle:

a) Cursor is on other display than focused window.
b) Press same tiling keystroke again.
✅ Window moves to target tile on screen where cursor.

Somewhen after a repeat cycle:

a) Cursor is on other display than focused window.
b) Press other tiling keystroke than before
❌ Actual: Window moves to target tile on its current screen
❗️ Expected: Window moves to target tile on screen where cursor.
- Because it is the first time that THIS keystroke was pressed. THIS keystroke did not yet repeat.

Configuration C

Repeated commands: Cycle through displays
Across Display Settings
- ☑️ Move window to display where cursor
- ☑️ Move cursor along with window across displays

Scenario

Focused window somewhere random on grid
Cursor on same screen
Press tiling keystroke (e.g. Top Left)

✅ Window moves to target tile on same screen.

Press same tiling keystroke again

✅ Window moves to target tile on other screen.
- Same keystroke repeated, thus Cycle through displays kicks in.
✅ Cursor moved to other screen too
- In accordance with Move cursor along with window across displays

Press same tiling keystroke again

❓ Nothing happens.
- To the user this feels counter intuitive when experiencing it in action.
  - You pressed the same keystroke again
  - You performed no mouse/trackpad activity. You did not intentionally move the cursor.
  - So it "feels" like a "just a keystroke repetition with no cursor movement involved".
- But the technical reality currently is this:
  - Cursor moved along automatically to center of window (due to Move cursor along with window across displays).
  - So window and cursor are on the same screen.
  - Therefore the repeat-counter was at 0 when the keystroke was triggered.
  - And as the tile was already at the target destination and the cursor on the same screen simply nothing visible happens.
🆗 Just disable Move cursor along with window across displays and you can still enjoy a mixed operation paradigm.
- Mouse/gaze first works with Move window to display where cursor
- Keyboard first still works with Next Display or Previous Display
- With the only downside of then not having Move cursor along with window across displays which if keyboard focused temporarily may not even matter, and if you need the cursor, then you do the effort of moving it along manually. Totally acceptable.
💡 Proposal A.6.💡 covers only the the exception for the first keystroke when the cursor is on another screen than the focused window. But the repeated keystroke where focused window and cursor are then on the same screen, then constitutes a keystroke repetition. So that won't fix the situation.
💡 We could be clever about it and optimize: Spot this particular arrival point and make a clever exception for it.
If (Repeated commands == Cycle through displays && Move cursor along with window across displays == ON && Move window to display where cursor == ON)
When a window has landed on a target position due to Move cursor along with window across displays the tileCommand("particular tile like e.g. Left").repetitions counter gets set to 1 so that it's next invocation already considers it a repetition.
The needed logic change shall NOT harm Configuration A in any way, because there the repetition works fine. If that would need rework, then don't do that optimization for Configuration C, which is far less likely/important than Configuration A.

Navigation Menu

Repository navigation

Move window to display where cursor #1908

Settings → Behavior → Across Display Settings: Gets new option + hint

Operation

Usability Rationale & Best Practise

The current workarounds for step 2 with Rectangle

Compatibility & Consistency

1) `Move cursor along with window across displays`

✅ Scenario 1a

✅ Scenario 1b

✅ Scenarios 1c

✅ Scenario 1c1

✅ Scenario 1c2

2) `Repeated commands` which involve display cycling

✅ Scenario 2a

✅ Scenario 2b

TL;DR

My testing feedback

My test setup

Terminology

UX assumptions & Terminology

Options that I ignored for interplay and at which values I left them

Options that I inspected on their own and in terms of interplay

Configuration X

Observations

Configuration A

Scenario

Configuration B

Scenario

Configuration C

Scenario

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Move window to display where cursor #1908

Description

Settings → Behavior → Across Display Settings: Gets new option + hint

Operation

Usability Rationale & Best Practise

The current workarounds for step 2 with Rectangle

Compatibility & Consistency

1) Move cursor along with window across displays

✅ Scenario 1a

✅ Scenario 1b

✅ Scenarios 1c

✅ Scenario 1c1

✅ Scenario 1c2

2) Repeated commands which involve display cycling

✅ Scenario 2a

✅ Scenario 2b

Activity

rxhanson commented on Oct 12, 2026

porg commented on Oct 12, 2026

Kiizon commented on Oct 13, 2026

porg commented on Oct 13, 2026

rxhanson commented on Oct 14, 2026

porg commented on Oct 14, 2026

porg commented on Oct 14, 2026

TL;DR

My testing feedback

My test setup

Terminology

UX assumptions & Terminology

Options that I ignored for interplay and at which values I left them

Options that I inspected on their own and in terms of interplay

Configuration X

Observations

Configuration A

Scenario

Configuration B

Scenario

Configuration C

Scenario

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions

1) `Move cursor along with window across displays`

2) `Repeated commands` which involve display cycling