[isaiahbenj94-star]

Why

The community drew a mockup of what the game folder's launcher should look like (green hookshot rail, hero with a Play disc,
"Build & Update", the version chain, and a status line that says what just happened). This PR builds that page for both
launcher implementations — the Qt builder (Windows) and the Tk builder in the Linux AppImage — and gives the rest of the Qt
builder the launcher's frame too, so the whole window reads as one design.

(On the Linux side, main already took the Tk builder to its own dark Slate theme — dark cards, Inter, Play's green. This PR
now sits on top of that: it keeps main's theme for the form and progress pages, and adds the mockup launcher page to it. The
branch includes a merge of main.)

What changes

• The launcher page (--launch <game folder>) in both builders: green rail with the hookshot and the game's version, the
  hero, the Play disc over it, "Build & Update" with the version chain over a scrim, and the "Hookshot: …" strip along the
  foot with the mockup's sentences.
  The hero picture is the player's own file, never ours: <game folder>/hookshot_hero.png when the folder has one, a
  generated dusk-green gradient otherwise. No game art ships in the builder (CONTRIBUTING, "the rule with no exceptions").
• The same chrome on every page of the Qt builder: the green rail at the left and a dark strip along the foot that carries
  each page's action row — Build/Play, Show log/Cancel, Open/Play, Back/Repair. The chrome stands down for the launch page,
  which draws its own pair inside, and the body takes the whole width back for it.
• A guard test (tests/test_builder_launch_hero.py, text-based like the other builder tests): the hero is read from the
  game folder only; no hero art ships anywhere under builder/; both builders draw the mockup's words; the Qt pages share the
  chrome; the preview fakes folder names, not game data.

Screenshots

The launcher page as the mockup draws it (Qt offscreen previews; the chain shows the preview's made-up tags):

With the player's own hero picture (a generated placeholder — no game data):

The rest of the Qt builder, same frame (offscreen previews):

The Linux (Tk) launcher, live under Xwayland with the AppImage's own Python, both states:

Tests

• python -I -B tests/test_builder_launch_hero.py — new, passes.
• python -I -B tests/run_all.py builder — the existing builder checks (jobs, scaling, status lines...) still pass; their
  greps still match.
• The Tk launcher was run for real with the AppImage's own Python against a made-up game folder (names only, no game data);
  Play, Update, the version chain and a hookshot_hero.png from the folder all behave.

[ghost]

Looks good. I read through launch_page.py, the window.py wiring and the Tk page; the hero is only ever read from <folder>/hookshot_hero.png, the preview folder is made-up file names only, paths.write_small / self.hook / game_ready all exist, and the new test is picked up by run_all's test_*.py discovery. The screenshots use a generated placeholder, so nothing from the game ships.

Nits, none blocking:

• Tk page: tk.PhotoImage(file=picture) raises TclError if hookshot_hero.png is corrupt or not a PNG/GIF, and that would break the launcher page. A try/except falling back to the gradient would be safer (the Qt side already handles a null pixmap).
• Tk page: the hero is only zoomed up, never scaled down, so a normal screenshot (1080p/4K) is just centre-cropped to the 650x560 canvas instead of cover-fit as the description says. Fine for a first cut.
• Qt: set_color(self.launch_version, "White") on the update chain is never reset to InkSoft if the launcher is shown again for another folder in the same session. Only matters in preview/dev.
• The tests are source-string checks, so they guard the rule but not behaviour. That's fine for the no-game-art rule.

CI hasn't run on this branch (no checks reported), so a Windows run of --launch <folder> as you suggested is still worth one look before merging.

[ghost]

Can you fix the screenshot links

[ghost]

I've withdrawn my approval for now, sorry for the back and forth. The page itself still looks good to me. The issue is the screenshots:

• They're committed as docs/launcher/*.png, so merging this would put five PNGs in the repo permanently just to illustrate the PR. They aren't referenced by any docs page.
• The description links them with relative paths (docs/launcher/up_to_date.png), which GitHub doesn't resolve in a PR description, so they show up broken.

Could you drag the images into the PR description instead (GitHub hosts them then) and drop the docs/launcher/ files from the commit? I'll re-approve once that's done.

[ghost]

Heads-up: this conflicts with main now (a lot landed today). Could you merge main into the branch (or rebase) and resolve the conflicts? Thanks!

[isaiahbenj94-star]

Screenshots posted, and code cleaned!

[ghost]

Thanks for adding the screenshots to the description, they render now. The PNGs are still in the PR though, so I can't re-approve yet.

The PR's files still list nine PNGs:

• docs/launcher/: hero_image.png, linux_tk_up_to_date.png, linux_tk_update_available.png, up_to_date.png, update_available.png
• docs/overhaul/: qt_build_page.png, qt_files_page.png, qt_problem_page.png, qt_ready_page.png

The latest commit only modified the docs/launcher/ ones and removed two from docs/overhaul/; the files are still there, and they live in the earlier commits' history too. Nothing links to them now that the description uses GitHub-hosted images, so they only add weight to the repo. Please delete all nine (docs/launcher/*.png and docs/overhaul/*.png). Because history would still hold them if merged as separate commits, either squash the branch, or rebuild it without the screenshot commits (5ad96253, e701e369 and the overhaul commit 70db3016 add them) so no commit adds a PNG. If this gets squash-merged, deleting the files in a final commit is enough.

The code changes since my approval look fine: the Tk rail now lays the logo over the gradient with subsample and falls back to the flattened copy on an older Tk, and the Qt launch page takes the full body width back while the chrome is hidden. No new issues there. The nits from my first review (corrupt hero PNG in Tk, hero only zoomed up) are unchanged and still non-blocking.

No CI checks have been reported on this branch; the PR is mergeable. Once the PNGs are out I'll approve.

[Joey-Magnus]

The nine screenshots are still in the PR: five in docs/launcher/*.png and four in docs/overhaul/*.png, added by 5ad9625, e701e36 and 70db301. Screenshots belong in the description, which you've already done, not in the repo. Please rebuild the branch without those commits, or squash it, so no commit adds a PNG.

Other points:

• builder/linux/hookshot_builder.py conflicts with main. Several Linux builder fixes landed in that file since (#2485, #2406, #2279, #2150), and the Tk launcher page is the Linux Play path, so this needs a careful merge.
• hookshot_builder.py:930: tk.PhotoImage(file=picture) still has no try/except. A corrupt or renamed hookshot_hero.png raises TclError and takes the launcher page down. Falling back to the gradient would fix it.
• The Windows release ships the .NET WPF builder (dotnet publish in windows-builder.yml), and no workflow builds the Qt builder. So "one design for every page" doesn't reach Windows players; it only reaches Linux and the Qt port. Whether the WPF builder should follow is a maintainer call.

[ghost]

This now conflicts with main in builder/linux/hookshot_builder.py. Could you merge main into the branch (or rebase) when you get a chance? I'll take another look once it's up to date.