Capture genuine macOS and Windows tray shots, fix the Windows icon #18

Merged

geusebio merged 1 commit from feature/tray-macos-windows-capture into main 2026-09-07 16:14:53 +00:00

Conversation 0 Commits 1 Files changed 26 +605 -287

geusebio commented 2026-09-07 12:27:23 +00:00

Owner

Copy link

What this does

Replaces the fake, CSS-dressed macOS/Windows tray screenshots with genuine
captures, per platform issue
#648.

Platform	Scene	Before	After
macOS	menu, running, built, failed	Linux GTK menu tinted blue	Genuine — captured via tart on Apple silicon
Windows	menu	Linux GTK menu tinted blue	Genuine — captured via an unattended Windows Server install on Proxmox
Windows	running, built, failed	Linux GTK menu tinted blue	Not captured this round — old fakes deleted rather than left mislabelled

themes/macos.css and themes/windows.css are deleted; the dressing
pipeline (run.sh's DRESSED/HERO) is retired entirely rather than kept
half-alive to paper over the Windows gap. docs/manual.md's "dressed for
other platforms" section is rewritten to show what's actually genuine per
platform instead of the retired disclaimer.

A real bug this surfaced

Windows never showed a tray icon at all, silently — Shell_NotifyIcon's
LoadImage call rejects the embedded PNG (it wants a real .ico
container) and fails in a way that logs a misleading "operation completed
successfully". Nobody had run genuine Windows before to notice. Fixed with
a platform-specific icon.ico, embedded only on Windows
(internal/tray/icon_windows.go / icon_other.go), rendered from the same
solo-mark SVG by hack/icons/render.sh.

What's still open (partial completion, by design)

This issue explicitly anticipated a partial hand-back being fine. What's
left, tracked back on #648:

• Windows running/built/failed. The top-level tray menu opens and
  photographs cleanly (see the screenshot below), but driving into a
  submenu (shop · #12 → a deployment row) never expanded it, keyboard-only,
  on this Windows Server 2022 build — see hack/tray-vm-capture/README.md
  for exactly what was tried. A session with real mouse access to the guest
  (Proxmox's vncproxy refused every connection attempt this session, for
  reasons unresolved) should just click it.
• rrru is down. The Proxmox mule the issue's plan was written around is
  unreachable — confirmed dead at the network layer (ARP failure from the
  bastion on its own LAN segment), not a sandboxing artifact. With the repo
  owner's go-ahead, macOS ran on the operator's own Apple-silicon Mac via
  tart instead, and Windows ran on grey-area (production) instead of the
  mule — both one-offs, not standing runners.
• No Packer template, no nightly runner yet. Both platforms were driven
  by hand this session (documented step by step in
  hack/tray-vm-capture/README.md) rather than by the one-command
  automation the issue's "Shape of the run" describes. The Windows
  autounattend.xml committed here is "what it should do", not "what ran" —
  a two-CD-ROM confusion in Windows Setup's own media detection meant most
  of the actual install was driven by hand; see the README for the
  workaround that wasn't fully proven either.

Evidence

macOS — all four states, genuine:

Windows — menu, genuine:

(Full set in docs/images/macos/applications/ and
docs/images/windows/applications/, and in the regenerated
docs/manual.md.)

Verified

• go build ./..., go test ./... clean on darwin/arm64 (native)
• Cross-compiles clean for GOOS=windows GOARCH=amd64 and confirmed
  rendering a real icon + real menu on an actual Windows Server 2022 guest
• hack/lint.sh (golangci-lint v2.13.2): 0 issues
• shellcheck -S warning clean on the touched/new shell scripts
• python3 hack/screenshot/manual.py check: docs/manual.md matches what
  a rebuild produces
• Proxmox VM (grey-area, vmid 104) destroyed after capture; temporary ISOs
  and helper servers on grey-area removed; local tart VM stopped (kept,
  not deleted, in case a follow-up session wants to reuse the ~25GB base
  image rather than re-pull it)

Closes #648 is deliberately not in this PR body — the issue stays open
for the Windows remainder above.

## What this does Replaces the fake, CSS-dressed macOS/Windows tray screenshots with genuine captures, per platform issue [#648](https://git.grey.ooo/Grey.ooo/Someones.Computer/issues/648). | Platform | Scene | Before | After | |---|---|---|---| | macOS | `menu`, `running`, `built`, `failed` | Linux GTK menu tinted blue | **Genuine** — captured via `tart` on Apple silicon | | Windows | `menu` | Linux GTK menu tinted blue | **Genuine** — captured via an unattended Windows Server install on Proxmox | | Windows | `running`, `built`, `failed` | Linux GTK menu tinted blue | **Not captured this round** — old fakes deleted rather than left mislabelled | `themes/macos.css` and `themes/windows.css` are deleted; the dressing pipeline (`run.sh`'s `DRESSED`/`HERO`) is retired entirely rather than kept half-alive to paper over the Windows gap. `docs/manual.md`'s "dressed for other platforms" section is rewritten to show what's actually genuine per platform instead of the retired disclaimer. ## A real bug this surfaced Windows never showed a tray icon at all, silently — `Shell_NotifyIcon`'s `LoadImage` call rejects the embedded PNG (it wants a real `.ico` container) and fails in a way that logs a misleading "operation completed successfully". Nobody had run genuine Windows before to notice. Fixed with a platform-specific `icon.ico`, embedded only on Windows (`internal/tray/icon_windows.go` / `icon_other.go`), rendered from the same solo-mark SVG by `hack/icons/render.sh`. ## What's still open (partial completion, by design) This issue explicitly anticipated a partial hand-back being fine. What's left, tracked back on #648: - **Windows `running`/`built`/`failed`.** The top-level tray menu opens and photographs cleanly (see the screenshot below), but driving *into* a submenu (`shop · #12` → a deployment row) never expanded it, keyboard-only, on this Windows Server 2022 build — see `hack/tray-vm-capture/README.md` for exactly what was tried. A session with real mouse access to the guest (Proxmox's `vncproxy` refused every connection attempt this session, for reasons unresolved) should just click it. - **rrru is down.** The Proxmox mule the issue's plan was written around is unreachable — confirmed dead at the network layer (ARP failure from the bastion on its own LAN segment), not a sandboxing artifact. With the repo owner's go-ahead, macOS ran on the operator's own Apple-silicon Mac via `tart` instead, and Windows ran on `grey-area` (production) instead of the mule — both one-offs, not standing runners. - **No Packer template, no nightly runner yet.** Both platforms were driven by hand this session (documented step by step in `hack/tray-vm-capture/README.md`) rather than by the one-command automation the issue's "Shape of the run" describes. The Windows `autounattend.xml` committed here is "what it should do", not "what ran" — a two-CD-ROM confusion in Windows Setup's own media detection meant most of the actual install was driven by hand; see the README for the workaround that wasn't fully proven either. ## Evidence **macOS — all four states, genuine:**   **Windows — menu, genuine:**  (Full set in `docs/images/macos/applications/` and `docs/images/windows/applications/`, and in the regenerated `docs/manual.md`.) ## Verified - `go build ./...`, `go test ./...` clean on darwin/arm64 (native) - Cross-compiles clean for `GOOS=windows GOARCH=amd64` and confirmed rendering a real icon + real menu on an actual Windows Server 2022 guest - `hack/lint.sh` (golangci-lint v2.13.2): 0 issues - `shellcheck -S warning` clean on the touched/new shell scripts - `python3 hack/screenshot/manual.py check`: `docs/manual.md` matches what a rebuild produces - Proxmox VM (grey-area, vmid 104) destroyed after capture; temporary ISOs and helper servers on grey-area removed; local `tart` VM stopped (kept, not deleted, in case a follow-up session wants to reuse the ~25GB base image rather than re-pull it) Closes #648 is deliberately **not** in this PR body — the issue stays open for the Windows remainder above.

geusebio added 1 commit 2026-09-07 12:27:24 +00:00

Capture genuine macOS and Windows tray shots, fix the Windows icon, retire the CSS dressing ... 04e3ec4877

macOS (all four `applications` scenes) and Windows (`menu`) are now real
captures off real hardware/a VM — via tart on Apple silicon and an
unattended Windows Server install on Proxmox, both driven and photographed
outside the guest (VNC / hypervisor screendump), never a guest-side
screenshot API. hack/tray-vm-capture/ has the recipe, what's proven and
what isn't.

Along the way: Windows never actually showed a tray icon at all —
Shell_NotifyIcon's LoadImage call silently rejects the embedded PNG, since
it wants a real .ico container, and logs a misleading "operation completed
successfully" on failure. Fixed with a platform-specific icon.ico (embedded
via icon_windows.go/icon_other.go), rendered from the same solo-mark SVG by
hack/icons/render.sh.

themes/macos.css and themes/windows.css are deleted — dressing is retired,
not extended to cover the gap. Windows running/built/failed are still
outstanding (this session's driving-the-submenu attempts stalled one level
deep, keyboard-only, on this Windows build); their old dressed-fake images
are deleted rather than left mislabelled, and docs/manual.md's "dressed for
other platforms" section is rewritten to show what's genuinely captured
per platform instead of the retired disclaimer.

Partial completion of platform issue #648: macOS is done, Windows menu is
done, Windows running/built/failed remain — tracked there rather than
closing it here.

geusebio changed title from WIP: Capture genuine macOS and Windows tray shots, fix the Windows icon to Capture genuine macOS and Windows tray shots, fix the Windows icon 2026-09-07 12:42:21 +00:00

geusebio merged commit 91881198a1 into main 2026-09-07 16:14:53 +00:00

geusebio deleted branch feature/tray-macos-windows-capture 2026-09-07 16:14:54 +00:00

geusebio referenced this pull request from a commit 2026-09-07 16:14:55 +00:00

Capture genuine macOS and Windows tray shots, fix the Windows icon (#18)

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels   

⏳in-progress

Someone is actively working this right now — do not start a second pass on it

No labels

⏳in-progress

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

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!18

No description provided.