Why saved window layouts break when your desk changes

Every tool that restores windows has to answer one question: what exactly are you restoring? The usual answer is a set of rectangles. It works until the desk changes, and then it fails in a way that feels like the tool is broken when it is really the model that is wrong.

This is worth being precise about, because "saved layouts break" is the kind of complaint that sounds like a bug report and is actually a design consequence.

What a saved layout really contains

A saved layout is a list of window frames: an application, a window, an origin, a size, and a display. Restoring it means putting each window back at the coordinates it had.

On a stable desk this is fine. The displays have the same identifiers, the same arrangement, the same usable areas after the menu bar and Dock are subtracted, and the same scaling. Nothing in the recording has gone stale, so replaying it produces what you expected.

The recording carries no information about why any of it was true. It cannot tell you that the terminal was narrow because it only ever holds log output, or that the reference document sat on the right because that is where you look when you are not typing. It knows position, not purpose.

The four ways a desk changes underneath it

The display set changes. This is the obvious one. Three displays at home, an ultrawide and a laptop at the office, a laptop alone on a train. A coordinate that pointed at the third display describes nothing when there is no third display, and the tool has to invent a policy — usually "put it on the main display" — with no idea whether that is sensible for this particular window.

Display identity changes without the hardware changing. Two identical monitors can swap which is which across a sleep cycle, a cable reconnection, or a firmware update, because the identifiers a system offers are not always as stable as they look. Apple's own NSScreen.screens documentation warns that the screen list should not be cached, since displays can be added, removed, or reconfigured dynamically. A layout keyed to a display that has quietly changed identity will confidently restore your work to the wrong screen.

The usable area changes. Same monitor, different available rectangle: a Dock that moved, a menu bar that grew, a notch, a scaling change, an external display running at a different resolution than last time. A frame that fitted exactly now overhangs, and a window that was flush against an edge is a few points off in a way that is visible and irritating.

The window set changes. The layout was recorded with one document open. Today there are three, or none. A recording has no way to express "whatever I have open in the editor belongs here" — only "this specific window belonged here" — so it either matches the wrong window or matches nothing.

None of these are exotic. Between them they cover almost every session that is not at the same desk twice.

Why "just handle the edge cases" does not work

The tempting fix is to keep the layout model and add rules. If the display is missing, fall back to the main one. If the frame does not fit, clamp it. If the window is gone, skip it.

Each rule is reasonable on its own. Together they produce a system whose behaviour you cannot predict, because the outcome depends on which rules fired in which order, and none of them knew what you were trying to achieve. You end up with a workspace that is nearly right in a different way every time, which is worse than one that is plainly wrong — a plainly wrong workspace you fix once, and a nearly-right one you fix continuously.

The deeper problem is that fallbacks derived from geometry can only ever guess at intent. Clamping a window to fit is a sensible operation on a rectangle and a meaningless one on a piece of work.

What survives a desk change

The thing that does not change when you move desks is what you were doing.

Orvial separates those two ideas explicitly. A Scene is the workspace you want for an activity — Development, Research, Present. An Environment is the physical setup available right now. The Scene is what you are doing; the Environment is what you have available.

That split matters because it moves the durable information out of the coordinates. A Scene can say that reference material belongs on a secondary display role without knowing whether that role is a 27-inch monitor at home or the right-hand third of an ultrawide at the office. When the desk changes, the role is still meaningful. A coordinate is not.

Resolution is then a real step rather than a fallback: take the Scene, take the Environment that exists, and work out the desired state that can actually be satisfied here. Where something genuinely differs — this Environment has no third display, so communication shares the laptop — that is an explicit decision the system can name, not a clamp applied silently.

Adaptation still has to be deterministic

"Adaptive" is a word that can mean two very different things, and only one of them is acceptable in a tool that controls your desktop.

It can mean: the same inputs produce the same resolution, every time, and any fallback that was applied is reported as a fallback. Or it can mean: the tool makes a plausible-looking guess that varies between runs.

The second is how you get a workspace you stop trusting. If you cannot predict what will happen when you plug in a monitor, you will start checking — and once you are checking, the tool has failed at the only thing it was for.

So resolution in Orvial is designed to be deterministic, and to distinguish a deliberate Environment-specific decision from a best-effort approximation. Those are different things and they are reported differently. What that reporting looks like is the subject of what verified workspace restoration actually means.

The honest limit

Orvial is in development. Everything above describes the model it is being built to, not measured behaviour of a shipped product — there is no public release, and this journal is not the place to pretend otherwise.

What can be said now is which problem is being solved. Saved layouts are not a bad implementation of workspace restoration. They are a good implementation of something else: replaying a recording. That is genuinely useful when your desk never changes, and it stops being useful the moment it does.

The alternative is not a cleverer recording. It is recording something else entirely.

If the vocabulary here is unfamiliar, the glossary defines each term in one sentence. The reasoning behind treating placement as desired state rather than position is in why window placement is a desired-state problem.