Named workspace modes: several saved arrangements, applied from the tray

[leaderdog-code]

Saved arrangements exist, but only one per display and applied by hand. The
idea is several named modes — streaming, accounting, a couple of workflows —
picked from the tray, with the screen populating itself.

What already works

• Slots per app per display, stored as offsets so moving a monitor is fine
• Save and apply per display, so a chaotic primary is left alone
• Extra windows left alone, missing apps leave empty slots

What a mode would add

Named modes. arrangement.json becomes {name: {slots: [...]}}. Tray gets
Save ▸ New name... / existing names, and Apply ▸ name. Naming needs a small Tk
prompt, which is fine since Tk already ships for the settings window.

Undo. Snapshot the current arrangement immediately before applying a mode,
so turning it off restores what was there beforehand. "Back to default
positions" is not implementable — apps have no default, only wherever they last
were — but "back to how it was before I clicked this" is well defined.

Launching what is missing. Record each app's executable path when saving,
start it on apply, wait for its window, then place it.

The part that does not generalise

Opening a second window of an already-running app is app-specific:

App	How
Brave / Chrome	--new-window
Explorer	pass a path
Discord	refuses, focuses the existing window

There is no general mechanism. Options: a small table of known apps, a
per-slot "command to open another window" field, or simply place whatever
windows exist and leave the user to open more. The last one is honest and
never surprises anyone, and is probably where to start.

Suggested order

1. Named modes over the existing slot machinery (arranges what is open)
2. Undo, via a pre-apply snapshot
3. Launch missing apps, first instance only
4. Extra windows, only if 1-3 prove worth using

Raised from real use: several Explorer windows for moving files around, and a
streaming layout with chat pinned to one side.

[leaderdog-code]

Another wanted behaviour: while a mode is on for a display, a window dragged onto that display drops into the next free slot, rather than needing Apply clicked again.

Effectively a tiling mode scoped to one screen. Fits the modes work because a mode already knows the slots and which display they belong to.

Worth keeping strictly opt-in and per display. The app currently never repositions a window after placement - it places on open, or when asked - precisely so nudging something does not make it spring back. Snapping on drag breaks that rule deliberately, so it should only ever apply to a screen the user has explicitly put into a mode, and never to the primary.

[leaderdog-code]

Tried and reverted: summoning an app out of the notification area when applying a layout.

ShowWindow(SW_SHOW) followed by SW_RESTORE does make a tray-hidden window visible again, and it is then placed correctly - tested on Signal, which went from being skipped to being arranged. But the window is dead: frame, title bar, nothing painted inside. Electron suspends its renderer while hidden and nothing external wakes it. Activating it and nudging its size to force WM_PAINT did not help either, and SetForegroundWindow was refused.

A black window looks like the app has crashed, which is worse than quietly skipping it, so the change is out.

If this is revisited, the only reliable route is the app's own tray handler - which means simulating a click on its notification-area icon, and that is fragile in a different way. Worth checking whether non-Electron tray apps behave better before assuming it is impossible in general.

[leaderdog-code]

Switching between modes needs defined semantics, not just apply-on-top-of-apply.

Going from mode 1 to mode 2 should:

1. Put back what mode 1 moved (the undo already recorded for it)
2. Then apply mode 2, recording its own undo

Otherwise mode 2 inherits a screen mode 1 rearranged, the undo history is lost, and turning everything off leaves windows wherever the last mode happened to put them rather than where they started.

That means the undo has to be per mode and survive switching, so it should live in the arrangement file next to the slots rather than only in memory. Suggested shape:

{name: {slots: [...], undo: {app+index: rect}}}

Undo keyed by app and ordinal rather than window handle, for the same reason slots are: handles do not survive a reboot.

Confirmed today by the user: clicking a tray icon populates the window properly, so tray apps are opened by hand and then arranged. Skipping them when hidden is correct behaviour, not a gap to fill.