noctalia

2026-11-04 20:35:46 +01:00
parent 5f4de5e60c
commit 86abc097f4
348 changed files with 10300 additions and 0 deletions
@@ -0,0 +1,45 @@
+# fastfetch
+
+Themes [fastfetch](https://github.com/fastfetch-cli/fastfetch) — sets `display.color.keys`,
+`display.color.title`, `display.percent.color.{green,yellow,red}` and `logo.color.{1,2}`.
+
+fastfetch's config (`~/.config/fastfetch/config.jsonc`) has no include/merge directive, so
+`apply.sh` merges the rendered color object into the user's real config.jsonc directly (`jq -s
+'.[0] * .[1]'`), preserving everything else in it (modules list, custom module config, etc.).
+
+**Known limitation: strict JSON only, not full JSONC.** `jq` (used for the merge) only parses
+strict JSON — `//`/`/* */` comments and trailing commas, both valid JSONC, will make `apply.sh`
+fail. It fails loudly with a clear message in that case rather than silently corrupting the file
+or applying nothing with no explanation. If your `config.jsonc` uses comments, remove them to use
+this template (fastfetch's own `--gen-config`/`--gen-config-force` output has none by default).
+Also fails loudly (rather than auto-creating one) if `config.jsonc` doesn't exist at all yet —
+run fastfetch once first to generate a default config.
+
+**Idempotency note**: the merge is guarded by comparing only the `logo`/`display` sub-objects
+semantically (`jq -S`), not the whole file's raw bytes — a naive whole-file `cmp` after a `jq`
+merge will never actually match hand-formatted JSON (`jq` re-serializes with its own canonical
+formatting), which silently defeats the guard and rewrites the file on every apply regardless of
+whether colors changed. Verified idempotent: running `apply.sh` twice with unchanged colors
+leaves the file's mtime and content completely untouched.
+
+**Known upstream bug (worked around here): `logo.color` silently drops pastel/light colors.**
+Confirmed live against fastfetch 2.66.0: a `logo.color.N` value is dropped with no error — the
+logo falls back to its default palette — whenever its truecolor SGR string (`38;2;R;G;B`) is
+exactly 16 characters, i.e. every one of R/G/B is a 3-digit number (`>=100`). That covers a large
+share of real accent colors, including most pastel/light theme colors. `display.color.keys`/
+`title`/`percent` are unaffected — only `logo.color.N` goes through the broken code path.
+Isolated by testing the exact byte-length trigger directly (both via `--logo-color-N` and via this
+same JSON key) with fully saturated colors of the same hue (worked) vs. desaturated/light colors
+producing a 16-char string (failed), including a control test with a non-pastel color that still
+had all three channels `>=100` (also failed) — confirming it's the string length, not the hue or
+lightness itself.
+
+`apply.sh` routes around it: whenever a `logo.color` value would trip the bug, the single
+*smallest* RGB channel is nudged down to 99 — the minimal change that drops the SGR string below
+16 characters, and since it's already the channel closest to the 100 boundary, it's the smallest
+possible perceptual shift (e.g. `#fff59b` → `#fff563`). An earlier version of this fix quantized
+to the nearest ANSI-256 cube color instead, but the 216-color cube only has 6 steps per channel,
+so a near-white pastel like `#fff59b` snapped to `#ffffaf` — visually just white on a small ascii
+logo. The channel-nudge keeps full 24-bit truecolor and stays close to the real color.
+
+Tested against fastfetch 2.66.0.