[acsandmann]

No description provided.

[sj-cstar]

Automated testing and notes, btw (on other note, I love the new stackline ❤️ ):

Ran #603 (e2a0c7f) today with display_mode = "shared", the built-in panel below a DELL U3225QE, and tested with rift-cli:

     +--------------------------+
     | DELL      (77,-1049)     |  workspaces 6-9
     |           1920x1049      |
     +--------------------------+
  +--------------------------------+
  | Built-in  (0,40) 2056x1289     |  workspaces 1-5
  +--------------------------------+

1. Hidden windows on the upper display land on the lower one. Rift parks them at (1996, 39), just past the DELL's bottom-right corner and over the built-in's right edge. macOS moves the window to the built-in's Space 20–170 ms later, and rift adopts it into the built-in's visible workspace. Moving a window to a hidden DELL workspace, or switching the DELL away from a workspace with windows, does it every time. sj-cstar/rift@166695c parks on the side edges instead and picks the placement that overlaps other displays least; it applies cleanly on feat/multidisplayv2.
2. A native move of a window rift parked counts as a user move. Even with better parking, a window rift hid itself should keep its workspace. WindowStore membership is meant to be authoritative.
3. Back-and-forth after a cross-display switch does nothing. With the DELL on 8 and the built-in on 4, switching to 2 from the DELL makes set_active_workspace_from set the built-in's previous to 8, dropping 4. workspace last then targets 8, already shown on the DELL, and nothing happens. With workspace_auto_back_and_forth, pressing 2 again does the same.
4. Switching to an empty workspace on another display keeps focus where it was. From the built-in, switching to 9 (empty, on the DELL) shows it there, but command focus stays on the built-in, so the next command acts there. Works when 9 has a window.
5. A command right after a cross-display move-node acts on the old display. move-node up then move-node down 17 ms apart leaves the window on the DELL: macOS moves its active display about 100 ms after the first move. sj-cstar/rift@07d4153 makes the window's new display the command context straight away.
6. move-workspace on a rule-bound workspace reverts later. Moving workspace 4 (bound to the built-in) to the DELL works, then reconcile_workspace_placements puts it back on the next display change: sleep/wake, plugging a display, a desktop switch. Either refuse the move, as feat: bind workspaces to displays #545 did, or let it update the pin.
7. workspace move-window <ws> <window-id> only finds windows on the focused display. find_window_by_idx filters on the command space, so a window on the other display is a no-op that still prints "Command executed successfully". sj-cstar/rift@ce6f6b9 resolves the window on any display.
8. rift-cli query workspaces is ambiguous in shared mode. It returns the whole catalog with one is_active per display and no display field, so select(.is_active == true) yields 1 and 8. The rift plugin in sketchybar-config does exactly that and highlights nothing. A display_uuid/space_id field and an is_focused flag would cover it.

Not carried over from #545:

9. settings.new_window_display (sj-cstar/rift@f26d998). My terminal hotkey activates Ghostty and sends ⌘N. With focus and the mouse on the DELL, the window opens on the built-in next to Ghostty's other windows, and the built-in switches workspace to show it.
10. Retrying apps that refused accessibility (sj-cstar/rift@732c76e). Registration still has no grace period outside JetBrains and Emacs, and activating an app without an app actor doesn't retry. fix: recover untracked windows on focus and activation #590 only recovers windows of apps that already have one.

Config:

11. A rule's display is ignored in independent mode with no validation warning. Identical monitors share a name, so a name-based rule picks the first.

Working well: move-window --follow and display move-window across displays with no snap-back, next/prev staying on each display's workspaces, focus across displays. Not tested yet: unplug/replug, sleep/wake, swipes, overview drops.

Happy to open PRs against feat/multidisplayv2 for 1, 5, 7, 9 and 10.

[sj-cstar]

Corrections to my list above:

• 3 and 4 were wrong. Back-and-forth is meant to return to the previous selection on the other display (shared_workspace_back_and_forth_follows_cross_display_selection), and switching to an empty workspace on another display does move command focus and the pointer there. I read keyboard focus staying on the old display's window as rift not moving; with no window in the target workspace, that is expected.
• 2 conflicts with topology_snapshot_preserves_workspace_placement_with_incomplete_delta. Its scenario 3 expects a window from a hidden workspace, reported on another connected display with no display change, to follow macOS. That is the same signal as the parking bounce, so I left it alone. With 1 fixed it no longer happens on two displays.

Fixes for the rest are on sj-cstar/rift:feat/multidisplayv2-sjpatches, one commit each on top of e2a0c7f:

• 1: park hidden windows where they overlap no other display
• 5: act on the display move-node just carried the focused window to
• 6: keep a rule-bound workspace on its display in move_workspace_to_display
• 7: find a window named by id on any display
• 8: display_uuid and is_focused in workspace queries
• 9: in shared mode, open new windows on the pointer's display, with no setting
• 10: retry attaching to apps that refused accessibility
• 11: warn about display rules outside shared mode and about display names matching several displays

Happy to open them as PRs against feat/multidisplayv2, together or one by one.