feat(dank16): Support full matugen color format output

[pdf]

Description

Currently dank16 only outputs a limited subset of matugen color formats. This makes it problematic to support any targets that do no support (stripped-)hex explicitly.

This change adds support for all standard upstream color formats.

Type of change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that changes existing behavior)
• Refactor / internal cleanup
• Documentation
• Other

Related issues

Screenshots / video

Checklist

• My code follows the conventions in CONTRIBUTING.md
• I have tested my changes locally
• New user-facing strings are wrapped in I18n.tr() with translator context, reusing existing terms where possible (N/A)
• Go changes: ran make fmt, added/updated tests, make test passes, and go mod tidy is clean
• QML changes: ran make lint-qml with no new warnings (N/A)
• I have opened a corresponding pull request in dlx-docs to document any new behaviors: https://github.com/AvengeMedia/DankLinux-Docs

[bbedward]

/claude review

[claude]

Compat note: this drops the "r", "g", "b" JSON keys (and changes them from numbers to strings). The in-repo templates under quickshell/matugen/templates/ only use hex/hex_stripped, so nothing here breaks, but any user template consuming dank16.colorN.r from dms dank16 --json silently renders empty after this. That makes the change breaking despite the "non-breaking" checkbox — either keep r/g/b as additional aliases or call it out in the PR description / release notes.

[pdf]

This is a legitimate complaint if users are consuming this data directly using the non-standard keys. I can revert the R, G, B keys to their original int values and add new Red, Green, Blue keys to carry the new string values if this is required.

[bbedward]

Nah I'm fine with this since it's non breaking

[claude]

Claude review

One real bug (negative hue for magenta-range colors), plus a compat note on the removed r/g/b keys.

• RGBToHSL drops the if h < 0 { h += 1.0 } wrap that RGBToHSV has, so math.Mod's sign-of-dividend result yields hue: -60.0 / hsl(-60.0, ...) for any color with red max and blue > green — core/internal/dank16/dank16.go:198
• ColorInfo no longer emits the r/g/b JSON keys, breaking user matugen templates that read them (in-repo templates are unaffected) — core/internal/dank16/dank16.go:34

Checked: HSL math against the existing HSV path, JSON field contract vs. in-repo matugen templates and all Go consumers of ColorInfo/VariantColorValue, and CONTRIBUTING rules (no i18n/QML surface; catalogs untouched). Model: claude-opus-5.

[bbedward]

/claude review

[claude]

Claude review

No issues found.

Re-checked after the push: the if h < 0 { h += 1.0 } wrap is now in RGBToHSL (core/internal/dank16/dank16.go:198) and TestRGBToHSL covers magenta, so the negative-hue bug from the last review is fixed. The r/g/b key change was accepted by @bbedward, so not re-raising it.

Checked: HSL math and the s = delta / (1 - |2l-1|) denominator against the delta==0 early return (unreachable divide-by-zero), hue/saturation/lightness rounding and %.1f formatting hand-verified for #625690, #1a1a1a, #f8f8f8, #fafafa, #0a0a0a, hue can't round to 360.0 for 8-bit inputs; all NewColorInfo callers pass a #-prefixed hex so the hex_alpha/alpha_hex prefix handling stays consistent; no in-repo consumer (matugen templates, dank.json, Theme.qml, terminals.go) reads anything but hex/hex_stripped; new test imports are used and en.json/template.json untouched. Model: claude-opus-5.

[pdf]

Do you want me to raise a docs change for this? The docs currently state the available keys as hex and hex_stripped. The docs also link to the now unmaintained matugen Github wiki rather than the Github Pages docs.

[purian23]

Do you want me to raise a docs change for this? The docs currently state the available keys as hex and hex_stripped. The docs also link to the now unmaintained matugen Github wiki rather than the Github Pages docs.

Yes, a docs PR would be appreciated with changes like these. Thanks for the feat!