Give the status row a rule, and retire the rows under a vanished app #13
No reviewers
Labels
No labels
⏳in-progress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
Grey.ooo/someones.computer_tray!13
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/tray-status-row-and-vanished-gestures"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Two platform issues, one change: they are the same file, the same
update/syncstatus-row contract, and fixing either alone rewrites the other's lines.
application keeps live toggles for deployments that no longer exist
loses every sentence it is given, to the sync that asked for it
(This is the tray repo, so
Closescannot reach them — they are closed by handonce the platform's submodule pin is bumped.)
#847 — a vanished application kept live toggles
updateretitled the row of an application that had stopped being listed andthen
continued, skippingupdateDeployments— the only caller that evertouches the gestures. So every deployment under it kept the state it had at the
last poll where the application still existed,
Activateincluded: a row sayingthe 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 ownsynced …line landed a millisecond later.update'sN new application(s) — restart sc-tray to list themwas worse than racy: itsown 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.
sayarms the hold;pollwrites onlyonce it has elapsed. The sync-failure line moved from
saytopoll, becausean 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 browseris left enabled under a vanishedapplication. 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; theseare 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 isa level deeper than this host draws — platform #844):
gone.png ·
menu.txt
#841 —
appeared. The status row now carries the notice instead ofsynced … · 2 applicationsover a menu holding one application:#841 —
in-flight. Acknowledgement mid-flight, outcome after, where bothruns previously recorded the freshness line:
scenes/in-flight/normalise.sedandscenes/refused/normalise.sedare 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
go test ./...go vet ./...hack/lint.shhack/coverage.shhack/screenshot/run.shmanual.py checkNew
internal/tray/status_test.gocovers the rule and drives a realsyncagainst an
httptestlisting.TestAnApplicationTheMenuCannotDrawIsReportedAndSurvivesItsOwnSyncis the test #841 asks for: reverted to the old
setStatusbehaviour it failswith
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.
WIP: Give the status row a rule, and retire the rows under a vanished appto Give the status row a rule, and retire the rows under a vanished app