Sync the Omarchy theme to Blender

[navarrotech]

Blender now follows the active Omarchy theme, including live switches while it is open.

Blender cannot be told to reload its theme, so the retint happens inside it:

• default/themed/blender.json.tpl maps the palette onto roughly 250 of Blender's theme colors: widgets, panels, editor backgrounds and headers, selection, text editor syntax, console, outliner, node categories, viewport selection and axes. It is rendered like every other template, so a theme can ship its own blender.json.
• default/blender/omarchy_theme.py is a Blender startup module. It resets to Blender's bundled Dark or Light preset (from mode), applies the JSON on top, and polls the file once a second, so a theme switch retints a running Blender within a second and leaves nothing stale from the previous theme. Fields the palette does not cover keep Blender's defaults.
• omarchy-theme-set-blender, added to post_theme_commands, keeps that module installed in every ~/.config/blender/<version>/scripts/startup/, which also covers Blender upgrades. The skip-blender-theme-changes toggle removes it instead.

blender.json is classified as colour-only in the staging test. The module only ever writes colour properties: a path that resolves to anything else is skipped with a warning, so a cloned theme's blender.json cannot reach other preferences.

Testing

• test/shell.d/blender-theme-test.sh covers install, upgrade, opt-out and absent Blender. When Blender is available it also renders every stock theme's blender.json and applies each inside headless Blender, failing on any path a Blender release renamed or retyped. I confirmed it fails on an unknown path and on a non-colour one.
• ./test/cli and theme-staging-test.sh pass.
• Verified by eye on Blender 5.2.1: Matter (dark) and Catppuccin Latte (light) applied live in a running instance, and switching light to dark produces exactly the same theme as setting dark directly.

A Blender config directory that does not exist yet (Blender never launched) gets the module on the next theme switch.

[llstrk]

One source-supported opt-out issue remains at 7663edeb5776.

Opt-out leaves the live Blender timer active

The installer deletes the startup module when skip-blender-theme-changes is enabled. However, the already registered timer checks only the theme file's stamp, not the toggle. Removing its source file does not call unregister() in the running process.

Source-derived sequence, not a live Blender reproduction:

Blender open with sync timer registered
  -> enable skip-blender-theme-changes
  -> switch Omarchy theme: startup file removed
  -> existing timer sees new blender.json and applies it

Impact: Opting out still allows subsequent theme changes to overwrite a custom Blender palette in that open session. Removal prevents sync on the next launch, rather than stopping the current session.

Suggested change: Check the skip toggle in the live callback before applying colors, with stamp handling that lets re-enabling pick up the current theme. Cover the already-registered callback case, not only deletion of the startup file. If next-launch-only opt-out is intentional, document the restart requirement explicitly.

---

Review information

Test scope: Source inspection of the installer, poller, staging integration and added tests. Blender execution, visual appearance and runtime timing were not tested; the author's reported runs were not reproduced.

Community review: Independent automated community review, unaffiliated with the Omarchy team, intended to help prepare PRs for their review.

Automated AI review: Astra Medium initial inspection, independent Opus 5.5 High and GPT 6 Sol Xhigh technical assessments, then Astra Medium source verification and synthesis.

[bjarneo]

This integration can use Omarchy’s existing theme-set hook and user templates without a new entry in post_theme_commands.

omarchy-theme-set-blender currently only installs or removes omarchy_theme.py. A shell hook can perform the same operations, including the skip-blender-theme-changes check.

A standalone integration could use these files:

• ~/.config/omarchy/hooks/theme-set.d/blender contains the current installer logic. Its BLENDER_MODULE_SOURCE points to the separately distributed Python module.
• ~/.config/omarchy/themed/blender.json.tpl contains the template from this PR.
• A companion omarchy_theme.py file supplies the startup module. The hook copies it into each existing Blender version’s scripts/startup/ directory.

Omarchy already renders user templates before it activates the theme and calls the theme-set hook. This produces ~/.local/state/omarchy/current/theme/blender.json, which the Blender module already reads.

The Python module still runs inside Blender and polls the JSON for live updates. The hook does not need to execute bpy in an external process. It installs the same startup module that this PR installs. Blender must load that module before live sync works, just as in this PR. The module’s existing toggle check also preserves opt-out behavior in an open Blender instance.

This preserves the PR’s design while allowing users to install the integration separately through the existing extension points.

[bjarneo]

Thank you for the work on this and for the tests. As outlined above, the existing theme hooks and user templates can support this integration, including live updates through the Blender startup module.

I’m closing this PR because those extension points already support this use case. Please consider sharing it as a standalone, opt-in integration for Blender users. Thank you again for the contribution.

[navarrotech]

Fixed in a8c4ed8. The running module now checks the skip-blender-theme-changes flag file on every poll, so an open Blender leaves its theme alone once sync is turned off. It also forgets the last-applied stamp, so turning sync back on applies the current theme immediately. blender-theme-test.sh covers this in headless Blender (fails on the previous commit, passes now).