Bernardo Magri
ff0f9d6359
All checks were successful
Check / eval (push) Successful in 3m59s
The logo was off-centre on the external when booting/shutting down docked. Both earlier diagnoses in this repo were WRONG, and that is the part worth keeping: Window.GetWidth() returns max_width (not head 0), and per-head sprites would have DUPLICATED the logo — the script plugin already builds one max_width x max_height canvas, centres every display inside it (script-lib-sprite.c:536) and draws sprites at (sprite.x - display.x), so a canvas-centred sprite is centred on every head. The arithmetic was right. The bug was TIME: every position was a top-level statement evaluated once at parse time. A head arriving/leaving mid-splash resizes the canvas, the plugin re-centres the displays, and frozen sprites end up off by (new_max - old_max)/2 on every head. One monitor never resizes the canvas — hence "only when docked". Fix: one layout(), re-run from the existing refresh callback on canvas change. The trap that cost two attempts (now a comment): in plymouth script a bare assignment inside a function writes the GLOBAL if that name already exists globally. So `canvas_width = Window.GetWidth()` updated global.canvas_width BEFORE the guard compared against it — always false, body never ran, splash rendered as a bare background, NO error logged. Isolated with a 20-line probe. Hence cw/ch. #145 rides along: a VT loads one keymap and knows nothing of per-device layouts, so the passphrase box types with the console layout — worth saying before three wrong tries on a disk you cannot read (same gap as #114, one step earlier). Fedora's mechanism does not port: ply_keymap_icon is a C widget in the two-step plugin (the script plugin has no keyboard API), fed from XKBLAYOUT in /etc/vconsole.conf, which NixOS never writes (plymouth's trace says `XKBLAYOUT: (null)`). So @LAYOUT@ is baked from services.xserver.xkb.layout like the palette — the FIRST of a comma list, since that is what the VT loads. Icon is plymouth's own keyboard.png (the same glyph Fedora shows), copied at build time so no GPL bytes enter the repo, recoloured to subtext. chmod +w after that copy: store files are 444 and recolor rewrites in place. Without it magick fails, the phase aborts, and EVERY LATER SED SILENTLY DOES NOT RUN — the theme shipped with @BG_R@ literals and I only caught it by reading the build log. Verified by render (tools/plymouth-preview.sh, real built theme): both heads centred, password dialog showing padlock + entry + keyboard icon and "us". V3 queued — only a real docked boot can resize a canvas. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Docs map
Where human and agent documentation lives. Do not invent a third tree for the same facts.
| Path | Audience | Role |
|---|---|---|
| ../README.md | Everyone | What Nomarchy is, install, options tables |
| REQUIREMENTS.md | Users + agents | Minimum system requirements (GPU/OpenGL, RAM, disk, UEFI) |
| VISION.md | Maintainers + agents | Product north star toward v1.0 and beyond — themes, not a task queue |
| ROADMAP.md | Maintainers + agents | Design/decision records + shipped log (historical ✓) |
| HARDWARE.md | Users + agents | Firmware, profiles, drivers, unsupported machines |
| TESTING.md | Maintainers + agents | Verification ladder, honesty rule, ISO/VM recipes |
| RECOVERY.md | Users | Broken theme/desktop/boot → undo |
| OVERRIDES.md | Users | Downstream Nix overrides |
| MIGRATION.md | Users | Existing NixOS → Nomarchy without reinstall |
| OMARCHY.md | Users | Coming from Omarchy — bindings/theme/install/config map |
Related (not under docs/)
| Path | Role |
|---|---|
| ../AGENTS.md | Agent entry point, any vendor/harness (CLAUDE.md symlinks to it) |
| ../agent/README.md | Agent instructions + executable loop state: BACKLOG, LOOP, VERIFICATION, … |
| ../.claude/ | Claude Code adapter only: permissions + subagent defs |
How work flows
VISION (what we want the product to feel like)
│
▼ human triages slices into…
BACKLOG (what's next, ordered — agents execute only this)
│
▼ lasting design notes after ship →
ROADMAP ✓ entries
Agents do not implement directly from VISION or ROADMAP. They take
the top actionable item in agent/BACKLOG.md (see agent/LOOP.md).
They may append PROPOSED pitches that reference VISION § … or
ROADMAP § ….