Global workflow¶

Saving and closing your workspace¶

Your work lives in the browser's local database while you use the app; the Save button in the header is what writes it out to your workspace file. Everything you change in between — a student added, a belt renamed, a script edited — leaves the workspace unsaved, and the header says so.

That indicator is stored with the data it describes, not merely held in memory: closing the app and opening it again later still reports the changes waiting to be exported, and Close — the one exit that wipes the local database — offers the save dialog rather than discarding them silently.

Where the file goes depends on your browser. On Chrome or Edge, the first save asks you to choose the file; every save after that writes straight back to it, with no dialog. The browser re-checks its permission when it restarts, so expect one confirmation per session — not one per save. Save as…, next to it, points the workspace at a different file and remembers that one instead.

On Firefox, saving goes through the download manager, as it does for any download: depending on your settings it either asks where to put the file or drops it straight into your downloads folder, and you move it over your workspace file yourself. Firefox offers no way for a page to write back to a file it opened, so this step cannot be automated there — and there is no Save as… button either, since Save already behaves that way. It is worth being careful with it, though: nothing stops you from replacing a file that is newer than what you are saving.

Leaving the page altogether (closing the browser tab, reloading) raises the browser's own "leave site?" confirmation as soon as anything is unsaved, be it workspace changes or an open script editor. See Editing a script for what happens to an edit in progress.

Starting a session¶

Automathon never reopens a workspace on its own. Each session starts on the welcome screen, and begins by opening a file.

That is deliberate, and it is the one rule that closes the worst gap. Every other way into a workspace goes through opening a file, which places it against what this browser has already seen and warns you if the two have drifted apart. Picking up whatever the browser happened to keep is the only path that skips that check — and skipping it is exactly how a stale copy gets worked on for an afternoon and then saved over a newer one. It matters most where a browser restores its tabs after a restart, which some systems do by default.

When everything had been saved, there is nothing to offer: the work is in a file, and the welcome screen names the workspace you last had open so you can find it. On Firefox this is worth more than it looks, since "saved" there often means "downloaded", and reopening makes you point at your real working file rather than whatever landed in your downloads folder.

When changes had not been saved — a tab closed past the browser's warning, or a crash — those changes exist in no file, so they are kept and offered: resume this session, or discard these changes. Discarding asks twice, since it is the one action in Automathon that destroys work on command. Nothing is ever deleted on your behalf: losing an afternoon to a crash would be a worse failure than the one all of this prevents.

Opening a workspace saved by an older version¶

A workspace file carries the format version it was written at, and Automathon's format grows as the app gains features. A file saved by an older version is upgraded as it opens: the app fills in whatever the newer format expects, using neutral values, so nothing you had set changes meaning and no feature switches itself on behind your back.

The upgrade happens in the app, not in your file. A banner says which format the workspace came from, and the workspace counts as unsaved from the moment it opens — Save is what writes the file back in the current format. Until you do, the file on disk is untouched and still opens in the older version of the app.

Two cases cannot be upgraded, and are refused with an explanation rather than opened halfway:

• a file saved by a newer version of Automathon than the one you are running — update the app, then open it;
• a file older than the oldest format this build still knows how to upgrade.

Why a workspace file remembers where it came from¶

Working in two places — a computer at home and one at school, a USB stick or a cloud folder between them — it is easy to end up with two copies of the same workspace that were each edited on their own. Whichever one you then save wins, and the other afternoon's work is gone.

So a workspace file carries its own ancestry: an identifier shared by every copy and descendant of that workspace, the revision it stands at, and a bounded record of the revisions it came through. That record is what lets Automathon find the last point two drifted-apart copies still agreed on, which is the only way to tell "added here" from "deleted there" — and therefore the only way to reconcile them without asking you about every single difference.

Two consequences worth knowing:

• the file grows a little, but not with your images and PDFs: those are stored once each, by content, and the history only refers to them. Attaching the same PDF to two tiles costs one copy, not two;
• a file written before this format existed starts its ancestry from the moment you first save it. Two such files that had already diverged share no common point, and cannot be reconciled automatically — that one pair has to be sorted out by hand.

When Automathon warns you¶

Two moments are checked, because they are the two ways an afternoon's work actually disappears.

Opening a file. Automathon remembers, per browser, which revisions it has already seen of each workspace. If the file you open turns out to be an older version of one you have since carried further here, or if the two have drifted apart, a red band says so. The file still opens — you asked for it — but you now know that saving it over the other copy would discard what that copy holds.

Being told nothing is the normal case: a file that simply carries on from what you last had is opened without comment.

Saving over a file that moved. On Chrome or Edge, where the destination is remembered, the file is re-read before being written. If something else wrote it in the meantime — a sync, another machine — you are asked rather than obeyed, with three ways out: save elsewhere, overwrite anyway, or cancel.

This check is only possible where the page can read the file it writes to, so it does not exist on Firefox. That is worth keeping in mind there.

Seeing your own unsaved changes¶

Mes modifications…, in the header, answers a question nothing else can: what am I about to write into the file? The database holds the current state and the file on disk the last saved one; reading either tells you nothing about the difference between them. (The little arrow beside it opens the rarer comparison, with a file — see the next section.)

It is the same report as below, with two differences. There is only one copy here, further along than it was, so nothing can conflict and everything lands in one column. And the columns read as time rather than as place: the past on the left, the present on the right — where a comparison with a file shows this workspace on the left and the other copy on the right, two places at one moment.

The version compared against is the last save, and normally there is nothing to choose. There is one exception, and it is the reason the choice exists at all: right after a merge, the point the workspace last reached is the merge itself, so the ordinary comparison shows only what you did since and hides what the merge brought in. A Depuis line then appears with two buttons — la fusion and avant la fusion — and the second is how a merge is reviewed after the fact. It goes away as soon as you save, the merge being then in the file like everything else.

This costs nothing to keep, which is why it is always available: the state at the last save is already stored, because the next save needs it to compute what changed. Going back past a merge only applies a reverse delta the workspace already carries.

Comparing two versions¶

Being told that two copies have drifted apart is of little help if finding out what differs means reading a workspace line by line — a divergence can be one mark among eight hundred. Comparer…, behind the arrow next to Mes modifications, answers that: it reads a file of your choice and lists what each side changed since the two parted. It is one click further away than the rest because it is for the day two copies drifted apart, not for every afternoon.

Nothing is written. The open workspace is untouched, and so is the file.

Every difference falls into one of four groups, and only the last one needs you:

• changed here only — your copy moved on, the file did not;
• changed in the file only — the reverse;
• changed on both sides to the same value — counted, not listed: there is nothing to decide;
• changed on both sides differently — a genuine conflict, listed first.

The report is read in two columns, labelled at the top and kept in the same order throughout: your copy on the left, the file on the right, whether what changed is a mark, a sub-theme or a whole script. Under each entry the values themselves are given — what a mark was before, and what each side made of it, so that 14 became 18 here and 9 there is not flattened into 18 versus 9. A side that did not move still shows its value, greyed: seeing what the other copy holds is half of reading a difference.

Colour says what will become of a value. The version that will be kept is pale green, the one it supersedes pale red. A conflict has neither until you settle it: both sides are amber, and turn green and red the moment you choose.

A value too long to read in a list — a script's whole content — is not quoted there: half a script is less use than none. It carries a voir les différences link instead, which opens the two versions side by side — same two columns, same split — line against line. The stretches both versions agree on are folded away, so what you read is the neighbourhood of each difference; clicking a fold opens it.

A progression is shown as a progression. Its thresholds are stored as positions into the belt scale, so début : 3 → 5 is exact and unreadable — what it means is that the sub-theme now starts a belt later, and that only shows as a picture. The report therefore draws the row of cells itself, on each side, with the panel's own colours: white for absent, green for solo, green with a dot for a merged cell, hatched for removed, dashed past the end of the scale. The cells the two versions disagree on are outlined, green on the side that will be kept and red on the other. The two numbers are not printed at all: they would only invite being read as numbers.

A group — a cell merge — is named by what it holds rather than by its rows: 5e, ceinture Jaune — groupe : Additions, Soustractions. And a sub-theme is named inside its theme and its level, because the same sub-theme name comes back from one level to the next.

A timestamp is left out altogether. It moves whenever anything else does, so a row whose only difference is its timestamp is not listed at all, and a timestamp never appears in the detail of a real change.

That last group is normally a handful of rows, even after a whole afternoon of work on each side. That is what having a common ancestor buys: everything both copies agree about falls away on its own, and what is left is short enough to read.

Two versions that share no revision at all cannot be compared this way — there is nothing to measure them against, and treating every difference as a conflict would be worse than saying so plainly. The report says so instead.

Merging the two¶

When the report finds something, it also offers to merge. Everything only one side changed is taken as it stands — that is the bulk of it, and you are not asked about any of it. Each real conflict carries two buttons, one under each column and both reading garder: which version a button keeps is said by where it is, under the values that let you decide. Its red conflit badge sits against the line between the two columns; once you have chosen, it goes pale and the side you kept is named. Merge stays unavailable until every one has been answered: there is no default side and no "most recent wins", because two machines' clocks disagree and a mark has no natural winner.

Two things are settled without asking. Ordering is merged rather than compared, so two people inserting rows in different places both get what they meant; and a cell merge whose sub-theme no longer reaches that belt is dropped, exactly as it would be if you moved the threshold by hand.

Merging changes the browser's database only. Both files on disk stay as they are, so you can look the result over, and simply closing without saving puts you back where you were. Once you are happy, save as usual.

The merged version records that it descends from both — which is why rewriting only one of the two files is enough. The other copy, when you next open it, sees a version that already contains its own work and fast-forwards instead of asking the same questions again.