Generate theme unlock art, and pre-build the menu caches during install - #6403
Open
dhh wants to merge 2 commits into
Open
Generate theme unlock art, and pre-build the menu caches during install#6403dhh wants to merge 2 commits into
dhh wants to merge 2 commits into
Conversation
Every theme shipped an unlock.png -- the Omarchy logo recolored, installed as the Plymouth boot logo and the SDDM login logo -- and a preview-unlock.png mocking up the boot password screen for the unlock switcher. For all but a handful of themes those files were mechanical: 17 of 22 unlock.png were the default logo recolored to the theme's accent, and 21 of 22 preview-unlock.png were exactly what omarchy-plymouth-preview renders from that logo plus the theme's background and foreground. Byte-for-byte, not approximately. That made a new theme's boot screen a manual asset step for something the palette already described, and it put 7MB of derived PNGs in the tree. Generate both on demand instead: - omarchy-plymouth-logo recolors default/plymouth/logo.png to the theme's accent, falling back to foreground for a minimal colors.toml. - omarchy-plymouth-preview-by-theme renders the preview from that logo and the palette, reusing the existing renderer through a new --no-open flag. Both cache under ~/.cache/omarchy/plymouth/<theme>/. The cache file is named after a hash of its inputs, so publishing it is a single atomic rename and no reader can see one run's image paired with another run's signature. The resolved theme directory is part of that hash, so a user theme shadowing a built-in of the same name never collides with it. A committed file still wins, so overriding is just dropping unlock.png or preview-unlock.png into the theme. kanagawa, lumon, tokyo-night, vantablack, and white keep their custom logos; the other 39 files are deleted. Two things fall out of this. omarchy-plymouth-list no longer gates on a preview file existing, so any theme with a colors.toml can style the boot screen -- including user themes, which previously could not. And omarchy-plymouth-current gains a pixel-content fallback: it identifies the active theme by cmp-ing the installed logo.png, and a machine that applied a theme before this change has one whose PNG metadata differs from the generated file even though every pixel matches. Verified generation reproduces the deleted files exactly: 17/17 logos and 21/22 previews at zero pixels different. The exception is lupine, whose committed preview was stale -- its entry field carried a tint from an older entry.png -- so it now renders what the boot screen actually draws. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The theme, background, and unlock selectors each render 1536x864 thumbnails the first time they open, so the first open of each menu on a new machine is the one slow one. Deleting the committed unlock previews made that worse: those previews now have to be generated too. omarchy-cache-warm builds all three up front. It runs from install/user/all.sh, which omarchy-finalize-user sources -- and the ISO runs that in the target chroot as the target user, so a freshly installed machine already has the caches and never pays for them at login. Users who install some other way get it from the same place, because omarchy-first-run calls finalize-user. A migration covers everyone already installed. Warming is best effort. It reports failures on stderr but always exits 0: sourced install leaves and migrations both run under bash -euo pipefail, and a thumbnail cache that can't be built is not a reason to abort user setup. Cold run is 6.6s of niced, idle-io work; re-running is 0.3s because every underlying cache short-circuits. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Every theme shipped two derived PNGs:
unlock.png(the Omarchy logo recolored, installed as the Plymouth boot logo and the SDDM login logo) andpreview-unlock.png(a 1080p mock of the boot password screen, used as the unlock switcher thumbnail).For nearly all of them those files were mechanical. 17 of 22
unlock.pngwere the default logo recolored to the theme'saccent, and 21 of 22preview-unlock.pngwere exactly whatomarchy-plymouth-previewrenders from that logo plus the theme'sbackgroundandforeground— byte-for-byte, not approximately. So a new theme's boot screen was a manual asset step for something the palette already described, and 7MB of derived PNGs sat in the tree.Generating it instead
omarchy-plymouth-logorecolorsdefault/plymouth/logo.pngto the theme'saccent(falling back toforegroundfor a minimalcolors.toml).omarchy-plymouth-preview-by-themerenders the preview from that logo and the palette, reusing the existing renderer through a new--no-openflag.Both cache under
~/.cache/omarchy/plymouth/<theme>/, named after a hash of their inputs so publishing is a single atomic rename. A committed file still wins, so overriding is just dropping the file into the theme.kanagawa,lumon,tokyo-night,vantablackandwhitekeep their custom logos; the other 39 files are deleted.Two things fall out of this.
omarchy-plymouth-listno longer gates on a preview file existing, so any theme with acolors.tomlcan style the boot screen — including user themes under~/.config/omarchy/themes/, which previously could not. Andomarchy-plymouth-currentgains a pixel-content fallback, because a machine that applied a theme before this change has an installedlogo.pngwhose PNG metadata differs from the generated file even though every pixel matches.Pre-building the caches
The theme, background, and unlock selectors each render 1536x864 thumbnails on first open, and deleting the committed previews means those have to be generated too.
omarchy-cache-warmbuilds all three up front.It runs from
install/user/all.sh, whichomarchy-finalize-usersources — and the ISO runs that in the target chroot as the target user, so a freshly installed machine already has the caches and never pays for them at login. Other install paths get it from the same place becauseomarchy-first-runcallsfinalize-user. A migration covers everyone already installed.Warming is best effort: it reports failures on stderr but always exits 0, since sourced install leaves and migrations both run under
bash -euo pipefailand a thumbnail cache that can't be built is no reason to abort user setup. Cold run is 6.6s of niced, idle-io work; re-running is 0.3s.Verification
Generation reproduces the deleted files exactly — 17/17 logos and 21/22 previews at zero pixels different. The exception is
lupine, whose committed preview was stale (its entry field carried a tint from an olderentry.png), so it now renders what the boot screen actually draws. All 23 rendered previews were inspected visually.omarchy-plymouth-currentwas checked against all four cases: legacy-metadata install, freshly generated logo, committed custom art, and an unknown logo. A user theme with onlybackgroundandforeground, one shadowing a built-in name, and one with spaces in its name all render correctly../test/allpasses (461).