Tender Sync Layouts #1814 · panel 854 px wide, 454 px tall on the Deck

Notes

1. 1

   The preview is the page. One row per platform with a change, the collections row built from the added and removed names, a total row. A platform that has left the run but still has shortcuts to remove is marked, not hidden. Every row is a focus stop, so the reader can walk the table and the region scrolls with them.

2. 2

   Three ways to end a preview. Apply, Refresh and Cancel sit under the table. Refresh is new: it discards the pending preview on both sides and computes another. These three replace Main's two buttons and Main's second-press discard.

3. 3

   Options. Skip preview is a saved setting now, read back on every mount. Force Full Sync is red and last in its group, with its one-line explanation; whether it gets a confirmation is an open decision, today it has none.

4. 4

   Steam memory. The same reading Main's status row shows, plus the last run's delta. When the last run paused on the budget, the session-budget card with Restart Steam now and Resume takes the top of the left column and the preview moves under it.

5. 5

   Last runs. Ten at most, newest first; each row is a focus stop with the start time, what the run covered and how it ended. A run that did not finish says so in the status word, not in a count.

What it costs

• The right column is 270 px: a run row gets one line of description and long platform lists are counted, not listed.
• The table has 520 px for a name and three numbers, which is enough; a fourth column would not fit beside a long platform name.
• The import choice (#1364, later) goes under the table and pushes Apply down; on the Deck the buttons are then a scroll away while a choice is offered.
• Two regions means two focus columns; moving from Apply to Force Full Sync is a right press, not a down press.

Notes

6. 6

   Two levels, from data the frontend already has. The plan event lists every unit up front with its ROM count and whether the fetch is expected to skip it; each progress frame names the running unit, its stage (fetching, covers, applying) and its item counter; the apply loop knows what each unit produced. Done units keep their result, the running unit gets its own bar, waiting units show what is planned for them. The rows are flatter and set smaller than the preview's rows on purpose: a plan of fourteen platforms and three collections has to fit the column without eating the height the total bar and Cancel need. The total bar and the estimate are the ones Main shows, read through one shared hook rather than a second copy of Main's derivation.

7. 7

   What each stage says. fetching counts ROM pages, covers counts downloads, applying counts shortcuts written, in the same row and the same bar. A pause on the session budget or a cancel leaves the table standing with the last state of every row, which is what the reader wants to see when deciding whether to resume.

What it costs

• The numbers come from Main's progress derivation, which lives inside the Main component today; a shared hook has to be lifted out of it before both pages can read it, and Main's progress tests move with it.
• Per-unit results are counted on the frontend as the apply loop runs; a page opened mid-run sees results only for units finished after it opened, unless the loop records them in a module store.
• Fourteen platforms and three collections fill the column; the region scrolls, and the running row stays where it is rather than being kept in view.