Spencer Bull
6baae0f556
Hermes Desktop installed under Install > AI kept its own palette while every other agent app retinted with the theme. Hermes' skin is its one theme unit for the desktop app, the TUI and the CLI, and its gateway watches the active skin file and broadcasts changes to every surface, so Omarchy publishes a skin named omarchy from a template on every theme switch and nothing Omarchy-specific goes upstream.
Activation goes through hermes config set, which writes the active profile's config and touches the skin so a running gateway repaints at once, and it only replaces Hermes' default skin so a choice made in Hermes stays. A theme switch runs that activation too when the desktop package is present and Hermes is still on its default, so a hand-over the installer missed is finished by the next switch; once the config names the skin a switch never starts Hermes. The desktop adopts a skin from a change broadcast rather than from the config it finds at connect time, and its first launch builds the runtime over minutes, so the installer starts --wait as a transient user unit that outlives the install terminal, activates once the runtime marker appears, republishes after the gateway is up, and reports to the journal. A migration hands the skin to existing Hermes Desktop installs through --activate, which also renders the skin for a theme applied before the template existed.
The generated file is validated before it is published, because Hermes parses it as YAML: only the name, a plain description and #rrggbb colours pass, so an unresolved palette key or a cloned theme's own hermes.yaml leaves the previous skin in place.
🤖 Generated by Fable 5.1 in Claude Code. Reviewed by Fable 5.1 code-review at high.
38 lines
1.7 KiB
Bash
Executable File
38 lines
1.7 KiB
Bash
Executable File
#!/bin/bash
|
|
|
|
# omarchy:summary=Install the Hermes desktop app
|
|
# omarchy:requires-sudo=true
|
|
|
|
set -e
|
|
|
|
# No CLI is installed here on purpose. Hermes Desktop only runs against a
|
|
# runtime built from its own commit, so it provisions one itself under
|
|
# ~/.hermes on first launch, which takes a few minutes and shows its own
|
|
# progress. Handing it the mise CLI instead fails: PyPI trails the tags, and
|
|
# the version gap fails the app's readiness probe with a 401.
|
|
echo "Installing Hermes Desktop..."
|
|
omarchy-pkg-add hermes-desktop
|
|
|
|
# If Hermes was already installed for the terminal, the app supersedes it: one
|
|
# machine, one Hermes. This drops that copy so the terminal, the default agent
|
|
# and the app all end up on the app's installation.
|
|
omarchy-install-hermes-cli || true
|
|
|
|
echo "Opening Hermes Desktop..."
|
|
setsid uwsm-app -- /usr/bin/hermes-desktop >/dev/null 2>&1 &
|
|
|
|
# The app builds its runtime on first launch, which takes minutes, and only a
|
|
# running Hermes can be told which skin to show. So the theme is handed over
|
|
# after the launch above, by a helper that waits for that runtime and then
|
|
# names the Omarchy skin through Hermes itself; the running app repaints. Only
|
|
# Hermes' own default is replaced, so a skin chosen in Hermes is never undone.
|
|
# It runs as its own unit, so this terminal closing cannot take it along and
|
|
# what it did is in the journal: journalctl --user -u omarchy-hermes-theme
|
|
echo "Matching Hermes to the current theme once it is set up..."
|
|
systemctl --user stop omarchy-hermes-theme.service 2>/dev/null || true
|
|
systemd-run --user --quiet --collect --unit=omarchy-hermes-theme omarchy-theme-set-hermes --wait
|
|
|
|
echo ""
|
|
echo "Hermes Desktop has been installed."
|
|
echo "Its first launch installs the Hermes runtime, which takes a few minutes."
|