Pimp My IDE / window shop
Back to garage
October 3, 2026 | desktop craft / task state / window management

Your desktop needs a transition contract.

The useful part of "tmux as the OS" is not the terminal grid. It is the promise that a task can detach, survive a display change, and return without losing its shape.

Treat docking, undocking, presenting, and resuming as named transitions. Preserve order. Hide private work by rule. Replay the last accepted arrangement instead of asking a model to improvise.

Replay, do not reshuffle

The feature worth stealing from tmux is survival.

The tmux project describes a terminal multiplexer that creates several terminals behind one screen. A session can detach, keep running, and attach again later.[1] That continuity matters more than the pane borders. The work persists when the viewing surface changes.

Mat Duggan's "Make tmux the OS" asks whether a normal desktop could keep that task-shaped continuity. His proposal uses a scrollable canvas, task groups, separate focal and glance areas, and deterministic display transitions. It also keeps the model away from direct window control. The model can propose a layout, while ordinary code previews and applies it.[2]

A desktop should remember the work, not merely the coordinates.

The strip already exists.

Niri arranges windows in columns on a strip that continues to the right. Opening a window does not resize the windows already there. Each monitor gets its own strip, and Niri restores monitor workspaces after a disconnect and reconnect when it can.[3]

That is a working answer to one part of the problem. The task has a stable left-to-right order. A narrower display changes how much of the strip is visible, not the order of the work. Niri also supports screen readers and can block selected windows from screencasts. Those details matter because a new layout is useless if it loses access or leaks a private pane.

Snapshots beat early filing.

WindowScape proposed a different answer in 2006. It saved photograph-like snapshots of expanded windows on a timeline. One window could appear in several task snapshots because each snapshot referred to the same underlying window. Users did not have to decide which single task owned a window before using it.[4]

The paper also names the failure. A timeline moves. Older snapshots fall out of view. WindowScape added a favorites area for arrangements worth keeping. That distinction still holds: recent states can expire, while a named task arrangement needs an explicit saved checkpoint.

Privacy cannot depend on attention.

Duggan tested an early idea that would slide private work away when the user became idle. Reading looks like idleness, so the system moved content while its owner was using it. The behavior hid work from the owner without reliably hiding it from a passerby.[2]

Use facts the computer can check. A presentation starts. A new display connects. A screencast targets a monitor. Then close private windows behind an explicit shutter until the user approves them. Do not infer privacy from typing speed, gaze, or an inactivity timer.

Write the transition before adding intelligence.

  1. Name the source and destination state, such as laptop to known dock.
  2. List what never changes, including task order, pinned windows, and task membership.
  3. List what may reflow, such as column width and visible window count.
  4. Define the privacy rule for a new display or active capture.
  5. Save an accepted arrangement and replay it on the matching display set.
  6. Require a preview and confirmation before any assistant proposes a new arrangement.

The result is less magical than an agent that continuously tidies the desktop. It is also easier to understand, undo, test, and trust.

Interactive makeover / task canvas transition rig

Change displays without scrambling the job.

Traditional purpose replaced: a display settings panel that only sees rectangles. Better version: choose the transition, select the promises, inspect the viewport, and copy a testable contract.

State
Reflow
Privacy
Receipt

Display state

Choose one target. The task cards keep the same order while the viewport changes.

Target display state
Required contract clauses

Transition preview

The cards do not move. Only the visible region and privacy shutter change.

Task strip / fixed orderLaptop / one viewport
01 / EditorCurrent code and terminal
02 / DocsReferences and issue
03 / ChatReview and status
04 / PrivateMail and credentials
Private shutter
2 of 4 contract clauses selected.Laptop keeps one focal viewport. The template still needs privacy and replay clauses.
This rig writes a review template. It does not move desktop windows, identify connected displays, or prove restore and privacy behavior.

Sources read

Source log and evidence boundary
  1. tmux repository and README, read October 3, 2026. The project defines tmux as a terminal multiplexer whose sessions can detach, continue in the background, and attach again.
  2. Mat Duggan, "Make tmux the OS", read October 3, 2026. The essay proposes a task-oriented scrollable canvas, deterministic display transitions, explicit privacy rules, and model proposals executed by constrained code. It also records failures around idle-based privacy and an infinite canvas with no aging policy.
  3. Niri repository and README, read October 3, 2026. The README documents scrollable tiling, stable existing window sizes, independent monitor strips, workspace restoration after monitor reconnection, screen-reader support, and screencast blocking rules.
  4. Craig Tashman, "WindowScape: A Task Oriented Window Manager," UIST 2006 author version, read October 3, 2026. The paper describes photograph-like task snapshots, windows represented in several groups, spatially stable miniatures, and a favorites area for snapshots worth retaining.

Artifact check. Niri is a public repository with a runnable compositor and install documentation. tmux is a mature public project with build instructions. The task canvas in this article is a browser demo, not a desktop extension or installable window manager.

Evidence boundary. This page did not install Niri, modify a desktop compositor, or run a multi-monitor restore test. The interaction demonstrates the shape of a transition contract. The named project behavior comes from the project documentation and cited paper.