Give the status row a rule, and retire the rows under a vanished app #13

Merged
geusebio merged 1 commit from fix/tray-status-row-and-vanished-gestures into main 2026-08-17 21:23:58 +00:00
Owner

Two platform issues, one change: they are the same file, the same update/sync
status-row contract, and fixing either alone rewrites the other's lines.

(This is the tray repo, so Closes cannot reach them — they are closed by hand
once the platform's submodule pin is bumped.)

#847 — a vanished application kept live toggles

update retitled the row of an application that had stopped being listed and
then continued, skipping updateDeployments — the only caller that ever
touches the gestures. So every deployment under it kept the state it had at the
last poll where the application still existed, Activate included: a row saying
the menu is out of date, sitting above a toggle that would post to an
application the platform no longer has.

The deployment-level disappearance a few lines down already did the right thing.
Both paths now share retire, so they cannot drift apart again.

#841 — the status row lost every sentence it was given

Three things write to that row; two were overwritten by the sync they themselves
asked for. A toggle says what it did and calls wake(), and the resync's own
synced … line landed a millisecond later. update's
N new application(s) — restart sc-tray to list them was worse than racy: its
own caller overwrote it unconditionally two lines later, so the branch was dead
code that read as working.

The row now has a rule — option 1 from the issue, the smallest of the three:
a sentence outranks the poll for 30s. say arms the hold; poll writes only
once it has elapsed. The sync-failure line moved from say to poll, because
an unreachable platform is the poll talking too, and a toggle's outcome from a
second ago is the more useful of the two sentences. The new-applications notice
re-arms on every poll that still finds one, so it stays up until the restart it
asks for.

Deviation worth flagging: Open in browser is left enabled under a vanished
application. The page may well still exist — the application could have moved
organization rather than been deleted — and a link that 404s is a smaller lie
than a toggle that fires. The issue calls this a judgement call either way.

Evidence

The capture suite (hack/screenshot/run.sh) re-run in full and blessed; these
are committed and commit-pinned, and the menu dumps are the machine-checked half.

#847vanished. The dump, which is where the gestures live (the submenu is
a level deeper than this host draws — platform #844):

    billing · gone — restart sc-tray
-  ○ main · failed (#9)
-    Activate main
+  main · gone
+    Activate main  [hidden]
     Confirm stop main  [hidden]

gone.png ·
menu.txt

#841appeared. The status row now carries the notice instead of
synced … · 2 applications over a menu holding one application:

The appeared scene after the poll

#841in-flight. Acknowledgement mid-flight, outcome after, where both
runs previously recorded the freshness line:

Mid-flight
Outcome

scenes/in-flight/normalise.sed and scenes/refused/normalise.sed are deleted.
Both existed only because the row's contents were a race — both say so in their
own comments, and in-flight's says outright that it is what should be deleted
when #841 gives the row a rule. The goldens now assert the real sentences.

The manual is regenerated from the same run, and the
scene prose that described these two as open bugs is rewritten.

Verification

Gate Result
go test ./... pass
go vet ./... pass
hack/lint.sh 0 issues
hack/coverage.sh internal/tray 29.9 → 38.3 (floor bumped; same figure measured under linux/amd64)
hack/screenshot/run.sh every scene captured, blessed, asserted
manual.py check pass
scene plans all 9 parse

New internal/tray/status_test.go covers the rule and drives a real sync
against an httptest listing. TestAnApplicationTheMenuCannotDrawIsReportedAndSurvivesItsOwnSync
is the test #841 asks for: reverted to the old setStatus behaviour it fails
with status row = "synced 22:33:35 · 1 application", want the restart notice.

Follow-up

The platform repo's submodule pin bump is a separate PR, per VCS.md — a pin move
is code and is never bundled.

Two platform issues, one change: they are the same file, the same `update`/`sync` status-row contract, and fixing either alone rewrites the other's lines. - https://git.grey.ooo/Grey.ooo/Someones.Computer/issues/847 — a vanished application keeps live toggles for deployments that no longer exist - https://git.grey.ooo/Grey.ooo/Someones.Computer/issues/841 — the status row loses every sentence it is given, to the sync that asked for it (This is the tray repo, so `Closes` cannot reach them — they are closed by hand once the platform's submodule pin is bumped.) ## #847 — a vanished application kept live toggles `update` retitled the row of an application that had stopped being listed and then `continue`d, skipping `updateDeployments` — the only caller that ever touches the gestures. So every deployment under it kept the state it had at the last poll where the application still existed, `Activate` included: a row saying the menu is out of date, sitting above a toggle that would post to an application the platform no longer has. The deployment-level disappearance a few lines down already did the right thing. Both paths now share `retire`, so they cannot drift apart again. ## #841 — the status row lost every sentence it was given Three things write to that row; two were overwritten by the sync they themselves asked for. A toggle says what it did and calls `wake()`, and the resync's own `synced …` line landed a millisecond later. `update`'s `N new application(s) — restart sc-tray to list them` was worse than racy: its own caller overwrote it unconditionally two lines later, so the branch was dead code that read as working. The row now has a rule — **option 1 from the issue**, the smallest of the three: a sentence outranks the poll for 30s. `say` arms the hold; `poll` writes only once it has elapsed. The sync-failure line moved from `say` to `poll`, because an unreachable platform is the poll talking too, and a toggle's outcome from a second ago is the more useful of the two sentences. The new-applications notice re-arms on every poll that still finds one, so it stays up until the restart it asks for. **Deviation worth flagging:** `Open in browser` is left enabled under a vanished application. The page may well still exist — the application could have moved organization rather than been deleted — and a link that 404s is a smaller lie than a toggle that fires. The issue calls this a judgement call either way. ## Evidence The capture suite (`hack/screenshot/run.sh`) re-run in full and blessed; these are committed and commit-pinned, and the menu dumps are the machine-checked half. **#847 — `vanished`.** The dump, which is where the gestures live (the submenu is a level deeper than this host draws — platform #844): ```diff billing · gone — restart sc-tray - ○ main · failed (#9) - Activate main + main · gone + Activate main [hidden] Confirm stop main [hidden] ``` [gone.png](https://git.grey.ooo/Grey.ooo/someones.computer_tray/raw/commit/c6fe2d6f38c80092ca2743b2236926a43965cbe9/docs/images/linux/vanished/gone.png) · [menu.txt](https://git.grey.ooo/Grey.ooo/someones.computer_tray/raw/commit/c6fe2d6f38c80092ca2743b2236926a43965cbe9/docs/images/linux/vanished/menu.txt) **#841 — `appeared`.** The status row now carries the notice instead of `synced … · 2 applications` over a menu holding one application: ![The appeared scene after the poll](https://git.grey.ooo/Grey.ooo/someones.computer_tray/raw/commit/c6fe2d6f38c80092ca2743b2236926a43965cbe9/docs/images/linux/appeared/after.png) **#841 — `in-flight`.** Acknowledgement mid-flight, outcome after, where both runs previously recorded the freshness line: ![Mid-flight](https://git.grey.ooo/Grey.ooo/someones.computer_tray/raw/commit/c6fe2d6f38c80092ca2743b2236926a43965cbe9/docs/images/linux/in-flight/in-flight.png) ![Outcome](https://git.grey.ooo/Grey.ooo/someones.computer_tray/raw/commit/c6fe2d6f38c80092ca2743b2236926a43965cbe9/docs/images/linux/in-flight/outcome.png) `scenes/in-flight/normalise.sed` and `scenes/refused/normalise.sed` are deleted. Both existed only because the row's contents were a race — both say so in their own comments, and in-flight's says outright that it is what should be deleted when #841 gives the row a rule. The goldens now assert the real sentences. [The manual](https://git.grey.ooo/Grey.ooo/someones.computer_tray/raw/commit/c6fe2d6f38c80092ca2743b2236926a43965cbe9/docs/manual.md) is regenerated from the same run, and the scene prose that described these two as open bugs is rewritten. ## Verification | Gate | Result | |---|---| | `go test ./...` | pass | | `go vet ./...` | pass | | `hack/lint.sh` | 0 issues | | `hack/coverage.sh` | internal/tray 29.9 → **38.3** (floor bumped; same figure measured under linux/amd64) | | `hack/screenshot/run.sh` | every scene captured, blessed, asserted | | `manual.py check` | pass | | scene plans | all 9 parse | New `internal/tray/status_test.go` covers the rule and drives a real `sync` against an `httptest` listing. `TestAnApplicationTheMenuCannotDrawIsReportedAndSurvivesItsOwnSync` is the test #841 asks for: reverted to the old `setStatus` behaviour it fails with `status row = "synced 22:33:35 · 1 application", want the restart notice`. ## Follow-up The platform repo's submodule pin bump is a separate PR, per VCS.md — a pin move is code and is never bundled.
Give the status row a rule, and retire the rows under a vanished app
All checks were successful
CI / build (pull_request) Successful in 3m28s
CI / captures (pull_request) Successful in 7m28s
c6fe2d6f38
Two bugs the capture suite photographed and nothing else could see.

**A vanished application kept live toggles** (platform #847). `update` retitled
the row of an application that had stopped being listed and then `continue`d,
skipping `updateDeployments` — the only caller that ever touches the gestures.
So every deployment under it kept the state it had at the last poll where the
application still existed, including an enabled `Activate` that would post to an
application the platform no longer has. The deployment-level disappearance was
already handled correctly a few lines down; both paths now share `retire`, so
they cannot drift apart again.

**The status row lost every sentence it was given** (platform #841). Three
things write to that row and two were overwritten by the sync they themselves
asked for: a toggle says what it did and calls `wake()`, and the resync's own
`synced …` line landed a millisecond later. `update`'s "N new application(s) —
restart sc-tray to list them" was worse than racy — its own caller overwrote it
unconditionally two lines later, making the branch dead code.

The row now has a rule, the smallest of the three the issue lists: a sentence
outranks the poll for 30s. `say` arms the hold; `poll` — the freshness line and
the sync-failure line, which is the poll talking too — writes only once the hold
has elapsed. The new-applications notice re-arms on every poll that still finds
one, so it stays up until the restart it asks for.

Verified by the capture suite, which is where both were found:

- `vanished` now dumps `main · gone` with `Activate main  [hidden]` under
  `billing · gone — restart sc-tray`, matching `staging · gone` above it.
- `appeared` now carries the restart notice on the status row instead of
  `synced … · 2 applications` over a menu holding one application.
- `in-flight` dumps the acknowledgement mid-flight and the outcome after,
  rather than the freshness line twice.

`scenes/in-flight/normalise.sed` and `scenes/refused/normalise.sed` are deleted:
both existed only because the row's contents were a race, both say so in their
own comments, and both goldens now assert the real sentence.

`Open in browser` is deliberately left enabled under a vanished application —
the page may well still exist (the application could have moved organization),
and a link that 404s is a smaller lie than a toggle that fires.

Coverage floor for internal/tray rises 29.9 → 38.3 (same figure on Linux).
geusebio changed title from WIP: Give the status row a rule, and retire the rows under a vanished app to Give the status row a rule, and retire the rows under a vanished app 2026-08-17 21:05:45 +00:00
geusebio scheduled this pull request to auto merge when all checks succeed 2026-08-17 21:06:39 +00:00
geusebio deleted branch fix/tray-status-row-and-vanished-gestures 2026-08-17 21:23:58 +00:00
Sign in to join this conversation.
No reviewers
No labels
in-progress
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
Grey.ooo/someones.computer_tray!13
No description provided.