ScreenState v1.4.0

Release notes

Profiles

A profile file renamed or copied by hand in the profiles folder could be left out of the manager's list yet still be applied when you signed in. Such a file is now named under the profile list with the reason; it is neither listed nor applied until it is put back under the file name the reason gives. Every change you make to a profile now acts on the file it was read from. Two profile names the manager treats as different can no longer end up sharing one file; saving a new profile never writes over another file. Profiles saved by earlier versions keep working as they are.

A profile file edited by hand to drop the format it is in is now named as unreadable rather than guessed at; so is one that no longer says whether an application was running.

Restoring

When a profile held two programs from one packaged application, a restore could place one window for both of them, so it could end up where the other program belonged. Each window now goes to one entry only, preferring the entry that names its program exactly; a program left without a window is reported as such.

Installing and updating

When setup closes a running copy of ScreenState before replacing it, it now recognises that copy by its full path in the install folder. A different program that happens to share the name is left alone.

The update check now opens only secure (https) links in your browser. A release pointing anywhere else is passed over and noted in the log.

ScreenState v1.3.0

Release notes

The program itself is unchanged in this release. Everything below concerns the website and the documents in the repository.

The website has a page for each job

The site used to be one long page. It is now three: the home page says what ScreenState is, how it works and how to support it; Features lists what it does, what it deliberately does not do and how it is built; Install carries the download and what to do after it. The site's own address is now ernster.dev/ScreenState, which the old address redirects to.

Installing starts from one card

The Install page carries a Windows card whose button fetches the setup program straight from the newest release, so the link cannot go stale. It shows the version, the file's size where GitHub can be reached, why Windows may show a SmartScreen warning and links to the release notes and to every release.

Fixes to the site

Every section had lost the space above and below it, so the page ran together as one block; the spacing is back. A browser holding an older copy of the stylesheet could also pair it with a newer page; each page now links its stylesheet by a fingerprint of its content, so a change always reaches the reader.

The decisions behind it, written down

DECISIONS-TRADEOFFS.md sets out the deliberate choices ScreenState rests on: what was chosen, what was given up for it, what each gains and what each costs. The README's list of documents links it.

ScreenState v1.2.0

Release notes

Applications are listed by name

The manager used to lead every application with its whole executable path, so the first thing you
read about PigeonPost was C:\Users\...\Programs\PigeonPost\PigeonPost.exe. Each application is
now listed by its name, with what the profile does with it underneath in quieter text:

PigeonPost
PigeonPost.exe · running · maximised · centre display
3300 × 2000

An application with several windows gets a line for each. The name is worked out from what was
recorded, so it needs nothing from the application itself: a program's file name without .exe, the
program an updater starts (Discord rather than Update) and a Store application's package name
(Claude rather than claude.exe). The capture review and the report of the last restore name
applications the same way.

Nothing that was captured is hidden. Rest the pointer on an application for exactly what was
recorded: its whole path, how it is recognised, each window's position and size and the monitor it
was captured on. The guide describes the new layout.

Displays are named by where they sit

A display used to be named by the long identity Windows gives it (such as
DISPLAY#HSJ1340#5&14514d51&0&UID4356) where it was named at all. The manager and the report now name
each display by where it sits among those connected: top, left, centre and right on a desk like
the one ScreenState was built on. The number Windows Settings shows is never used, since it was
measured disagreeing with where the screens actually are.

A restore keeps the names it started with. If a display comes or goes part way through, the others
keep their names rather than being renamed for the new arrangement, so every position in a report
means one display from start to finish.

The report says, for example, that a window was placed maximised on the centre display; that a
window whose display is not connected went to the top display instead; that the left display went
away during a restore. The identities are still there when you need them: resting the pointer
on the report's summary lists which display each position meant and the log records the same
pairing whenever a restore reads the displays or they change.

Apply keeps windows in the order it found them

Pressing Apply could reshuffle which window was on top of which. A window placed maximised came up
above the windows that had been in front of it: Windows Terminal, sitting behind Claude on the same
display, ended up on top of it. Placing a window now leaves it where it was among the others.

Windows come back in front of one another as they were

A capture now records which of the profile's windows is in front of which. At the end of a restore,
after sign-in or Apply, those windows are put back in that order before the message says the
desktop is ready. Until now a sign-in, which builds the desktop from nothing, left the windows in
whatever order the applications happened to start in, so a window you kept behind another had to be
sent back by hand after every reboot.

The order is set once and then left alone. Nothing is activated to do it, so the keyboard stays
where it was. If you press a key or click before the restore gets that far, the order is left as it
came up and the report says so. An application that brings its own window forward later is not
fought. Profiles captured before this release hold no order, so they behave exactly as before;
capture again to record one. Where the order cannot be read during a capture, the review says so
before anything is saved.

A dialog keeps the manager open until it is closed

With a dialog up in the manager (the report of a restore, Settings, About and the rest), the cross
in the window's title bar still worked: it sent the manager to the notification area with the
dialog still open inside it. A dialog now holds the window as a dialog should. The cross is greyed
while one is up and does nothing; nor do Alt+F4 or the taskbar button's Close. Close the dialog and
the cross puts the manager away as before. Quitting still quits, dialog or not.

ScreenState v1.1.0

Release notes

A new layout for the manager

The main screen is now three parts. The profiles run down the left; what the selected profile
arranges fills the middle, with every path shown whole; the buttons run down the right, Apply at the
top and Close and Quit at the foot above the donation button. The settings moved to a dialog of
their own behind the new gear button at the top, set apart from the theme and Help buttons by a
rule. The button that used to open a profile's applications in a dialog has gone, since they are
now on screen whenever the profile is.

The donation button says nothing is held back

Resting the pointer on the donation button now says first that ScreenState is free and stays free:
no paid tier, no licence key, no feature held back. It used to say only that the button buys the
author a drink, leaving that promise to the guide.

Setting how long a restore waits

How long a restore keeps waiting for windows that have not appeared is now yours to set, in the
settings, anywhere from 1 to 60 minutes. It was always 15, which is still what you get until you
change it. It counts from the moment the restore begins, whether at sign-in or from Apply. A change
governs the next restore without anything being restarted.

Stopping a restore

A restore applied from the manager can now be stopped: the Applying panel carries "Stop the
restore". It stops before its next action; everything already placed stays where it is and the
report says the restore was cancelled.

The tray after a restore

The tray icon's tooltip is brought up to date after every restore, whether it was started at
sign-in, from the tray or from the manager, so it no longer describes the one before.

When a restore leaves an application it could not start or place, the tray icon now carries a red
badge in its corner until a restore completes. It is drawn in the product's own colours, in the
light theme or the dark one as Windows is set.

Starting it by hand arranges nothing

Starting the agent from its shortcut used to restore the default profile, so relaunching it moved
the windows you were working in and put the "desktop is prepared" message up over the manager you
had asked for. Now only signing in arranges the desktop by itself; starting it any other way opens
the manager and moves nothing. Apply is there when you want the desktop arranged.

The message gets out of the manager's way

Opening the manager, from the tray, by starting it again or when an update is offered, now closes
the message that says the desktop is being prepared, which used to sit over the window you had just
opened until your next key press. A restore still under way carries on.

Closing the splash early

A click on the message that says the desktop is being prepared has always closed it. It also
counted as you taking over the desktop: every application still being waited for was given up and
the taskbar buttons were rebuilt without waiting for them to stop flashing. Now a click on the
message closes it and nothing more; the restore carries on. A key press still means you have taken
over, as does a click anywhere else.

A sign-in that closes windows finishes on its own

With closing turned on, the restore at sign-in asks the windows the profile does not name to close,
then waits for them to go. It could miss them going to the notification area and wait on until your
first key press or click; that press then counted as you taking over, so the wait for the taskbar
buttons to stop flashing was skipped and they could be left red. It now hears each window go, so the
restore finishes by itself: the buttons are rebuilt once the flashing has stopped and the message
says the desktop is ready without being touched. It also waits only for the windows it asked; one
that appears afterwards no longer holds it up.

Maximised windows are placed without taking the front

Placing a maximised window activated it, which lit its taskbar button and could take the keyboard
from the window you were typing in, most of all after pressing Apply. It is now maximised in a way
that leaves the active window alone. You may see each maximised window minimise and come straight
back as it is placed.

Taskbar buttons after a sign-in

Once a sign-in restore has placed everything, the taskbar button of each window is rebuilt so no
button is left marked. If one button could not be rebuilt, the rest used to be skipped and the log
said nothing about how many had been. Now a button that cannot be rebuilt is skipped on its own:
every other button is still rebuilt and the log says how many were and how many could not be.

Packaged applications after an update

A packaged application such as Claude installs under a path carrying its version. Once an update
had moved that path, its window no longer matched the profile: it was left where it was, then put
away as a window the profile does not name. A window is now matched by the model id kept beside the
path, so the application is placed after an update without the profile being recaptured. A profile
saved before the model id was kept, which names the application by its model id alone, is matched
the same way.

A profile that cannot be read is named in the manager

A profile file that could not be read (or was written by a newer version) used to vanish from the
list with the reason only in the log. It is now named under the list with the reason, while the
profiles that can be read are listed as usual. The file is still left exactly as it is. A profile
folder that cannot be read at all no longer stops the program before its window opens; the
manager says so instead.

No window titles in the log

The report of the restore that runs at sign-in is written into the log. It named each window it
put away or asked to close by its title. A title can say what you were working on, so it has
no place in a file that is kept. Those windows are now named by their application, the way every
other line of the report names them, in the log and in the report the manager shows alike.

The log keeps the last ten restores

The log used to start afresh once it passed 1 MB, which could throw away the very restore you were
trying to look into. Each start now cuts it down to the ten most recent restores, each with the
line saying which build ran it; a log holding fewer is kept whole however long it is.

ScreenState v1.0.0

Release notes

The first release of ScreenState: window layout profiles for Windows. Sign in and the desktop
arranges itself.

Profiles

Capture the desktop as it stands and ScreenState lists every application it found, with where each
window sits, which display it is on and whether it is maximised. Untick anything you want left out,
name the profile and save; nothing is written until you confirm. A cancelled capture leaves
nothing behind. A window that cannot be read is named in the review rather than dropped in silence.

Profiles can be renamed, deleted (after a confirmation naming the profile) and marked as the
default, which is the one applied after you sign in. While there is only one profile, it is the
default. What a profile arranges opens in a dialog of its own, where each application can be taken
out.

Each profile is a small JSON file in your own folder, written so that an interruption leaves either
the old file or the new one, never half of either. A profile from a format this version does not
understand is left untouched and said to be skipped.

Restoring

At sign-in ScreenState waits in the notification area and restores the default profile without
opening a window. It starts every application the profile records as running and places each
window the moment it appears, without waiting for the others. A message on every display says the
desktop is being prepared, then that it is ready (or how many applications did not start); a click or
a key press closes it.

A restore acts on what Windows reports: a window appearing, moving or going, the displays changing.
Your first key press or click (or the ceiling of 15 minutes) ends any wait for something
that is not coming. A window that moves itself after being placed is put back once; after that it is left
alone rather than fought over.

Any profile can also be applied on demand from the tray menu or the manager, with a bar showing how
far it has got. A restore asked for while one is running replaces it, leaving everything already
placed where it is.

Getting it right on a real desktop

• Displays are known by the identity Windows gives each screen, so two monitors of the same
  model are never confused. A display that has gone sends its windows to the primary one; displays
  changing mid-restore do not stop it; a window is always kept on a screen you can reach.
• Applications are named by what survives their updates. A packaged one such as Claude, whose
  install path moves with every version, keeps its model id beside the path so it can still be
  started. An application that should have several windows gets each one back.
• Nothing takes the keyboard. Applications are started and windows placed without making any of
  them the active window, so whatever you are typing into keeps the keyboard.
• The taskbar comes back clean. No button is left marked, red from a refused request for
  attention or grey without its icon.
• Windows a profile does not name are minimised once the restore is done. At sign-in they can
  be closed instead, if you turn that on; a window that will not close is minimised.

Safety

ScreenState never ends a program and never asks for administrator rights. Everything it writes is
in your own folders. It keeps a step log of every restore and a report of the last one, naming each
application it could not satisfy and why; the report is in the tray menu and the manager's Help.

Setup

One file installs, updates, goes back a version, repairs, reinstalls and uninstalls, all for your
account alone. Installing arranges nothing: the profile is applied at your next sign-in. Uninstalling
leaves your profiles unless you tick the box that removes them.

Updates

Once per run ScreenState asks whether a newer version has been released and offers the download if
there is one, with the choice to skip that version. The check carries nothing about you and can be
turned off, after which ScreenState makes no network connection at all.