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.