[joshhattan]

What

Three fixes for multi-workspace / multi-monitor use, one commit each:

1. A manual move of the Blip window now sticks. sameAddress() in BlipWindow.qml compared ownToplevel.lastIpcObject.address (0x5b5a…) with the raw movewindowv2 event address (5b5a…, no prefix) as plain strings, so it never matched. The reason: "move" path from fix: keep the app on its workspace after idle #87 was therefore never taken, and ~400ms later strayReturn read the move as a stray remap and sent the window back to its old home. Both sides are now stripped of 0x before comparing.
2. The bar popout opens on the screen whose icon was clicked. The panel only exists on the leader widget (first screen). Clicks on another screen's bar were forwarded as a bare toggle, so the popout always anchored to the leader's bar. Followers now send toggleon <screen>; the leader finds that screen's widget with bar.moduleWidgets(), re-anchors the panel to its button and bar, then opens it (the popout takes its screen from its anchor).
3. SUPER+CTRL+<n> opens the popout on any screen, not just the first. Omarchy routes a panel hotkey to the widget on the focused screen, but only the leader owns a panel, so on any other screen open() was a silent no-op that still reported success (no summon: warning, the hotkey just did nothing). open() now goes through openOn(screen): the leader re-anchors to the asked-for screen and opens; a follower forwards to the leader over IPC like a click does. The new verb is openon, not toggleon, because a hotkey that means "open" must not close a panel that is already up. close() on a follower forwards too.

Why

• Dragging/moving the window to another workspace (SUPER+SHIFT+N) appeared to work, then it jumped back to the old workspace. Traced on Hyprland's raw event socket: movewindowv2 …,6,6 followed ~400ms later by movewindowv2 …,1,1. The window's saved home was never updated, so it could not be moved off its first workspace.
• On a dual-monitor setup the popout only ever opened on the first monitor, even when clicking the icon on the second monitor's bar.
• Fix 3 is the same gap on the keyboard path: with the second monitor focused, SUPER+CTRL+1 did nothing at all. Omarchy's panel hotkeys reach Blip: expose opened on the bar widget #38 made the hotkey reach the widget (open/close/opened); this makes it work when that widget is a follower. Fix 3 reuses the anchoring from fix 2, which is why it belongs in this PR.

The DEVLOG entry for #87 verified that a stray move is returned but not that a deliberate move is saved; QML has no unit tests and ui.test.ts only asserts that the string sameAddress exists, so neither path was covered. Fix 3 adds a ui.test.ts assertion that the follower forwards, that openOn never toggles, and that close() forwards too (it fails against the previous BarWidget.qml).

How it was verified

• bun test is green (561 pass)
• Any send/receive behavior was exercised against my own number only — no send/receive behavior touched
• UI change → screenshot attached (no screenshot; verified with hyprctl layers instead, below)
• Touches an invariant in CLAUDE.md → named below; doc not changed

Live checks on Hyprland with two monitors (DP-1, DP-2):

• Before fix 1: dispatched a move to workspace 6, event socket showed the automatic move back to 1. After: window stayed on 6 and window.json saved "workspace":"6".
• Fix 2: ipc call nixfred.blip toggleon DP-2 puts omarchy-keyboard-panel on DP-2; toggleon DP-1 puts it on DP-1. I did not physically click the DP-2 bar icon; that path calls the same toggleon IPC with ownScreen.name.
• Fix 3: with DP-2 focused, the shell's togglePanelAt right 1 (what SUPER+CTRL+1 runs) previously produced no omarchy-keyboard-panel layer; after the fix it does, and the popout is visible on DP-2. Physically pressing SUPER+CTRL+1 on DP-2 opens it. The qs ipc verb openon <screen> is registered after omarchy-restart-shell.
• No new QML errors in qs log after omarchy-restart-shell.

Invariants touched: "The app window is RECREATED on show, never re-mapped" (save workspace only from a user movewindowv2). Fix 1 makes that behaviour actually happen; the documented invariant is unchanged. Fix 3 touches none.

[nixfred]

Merged, and shipped in 2.6.0. Thank you, this is a good catch.

The address fix is the one I want to call out. reason: "move" has been dead code since #87 shipped it, because the two sides were never the same string, and nothing covered it: the #87 devlog proved a stray move gets returned but never that a deliberate move gets saved, and ui.test.ts only asserted the literal sameAddress existed. Confirmed both formats here on gus before merging:

socket2:                activewindowv2>>5b160312f310
hyprctl clients -j:     "0x5b1604430290"

How it was integrated: your branch was based on b5cafc2, three commits behind, so it was cherry-picked onto current main first. Only CHANGELOG.md conflicted. bun test 622 pass, 0 fail.

Verified here on the live shell, not just read: deployed, restarted, qs log clean for nixfred.blip, and every popout verb driven (open, close, toggle, toggleon, openon), plus a screenshot of the panel rendering under its bar icon.

And the multi-monitor half got verified after all. I said in the merge commit that I could not check it, because this machine had one output attached. A second one then appeared mid-session (an iPad stream at 5120,0), and it turned out to be Quickshell.screens[0], so it held the panel and the 5120x1440 desktop monitor was the follower. That is your exact case:

open              -> panel on the leader        (5120 0 960 540)
openon DVI-I-1    -> panel re-anchored there    (0 0 5120 1440)

Your separate open-only verb was the right call, and it meshes with Omarchy's own routing better than I expected: BarModel.pickPanelSlot prefers an already-open copy, so the next press still reaches the leader and closes it. The open-only verb cannot strand a panel.

One thing you could not have known about, and it is not yours to fix. The follower-to-leader forward hardcodes qs -p /usr/share/omarchy/shell. That is correct on a stock install and it predates your PR (four such calls already, yours added two more in the same style, which is exactly right per house rule "match existing style"). On this machine the shell runs from a dev link, so every forward exits 255 with No running instances and the summon still reports ok. Your fix is inert here for that reason alone, and so is the pre-existing click forward. I am raising it separately as its own change.

Still open from #110: no X handle found for you anywhere public. If you want credit in the weekly post under a handle, say the word and I will use it; otherwise you are credited as joshhattan.