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.