[idea] Let plugin panes inherit Herdr’s resolved theme

[akramdotsh]

idea / problem

Plugin panes can render terminal UIs, but they cannot see the Herdr theme that launched them. They must hard-code colors or rely on terminal defaults, so they can look disconnected from Herdr when users switch themes.

requested change

Expose Herdr’s already-resolved palette to pane processes as a launch-time, pane-only snapshot. My preference is a protected environment value rather than a mutable socket API: plugin panes only need the theme they launched with, while actions, events, and startup processes should not receive presentation state.

I have this working in a fork and have tested it with dark, light, and terminal-default themes. If this direction fits Herdr, I’m happy to adapt it to the shape you prefer and contribute a small PR after an accepted issue and /approve @Akram012388.

why you want this

I’m building herdr-checkin, a popup plugin with Queue and Agents views. Theme inheritance lets it feel native instead of shipping its own competing color scheme.

This is separate from #1733: that discussion concerns modal popup presentation, while this proposal is only about theme data available to plugin panes.

[alesch]

I am interested in this. Could you somehow hare your patch, please? @Akram012388

[akramdotsh]

@alesch Here’s the patch from when I prototyped this — launch-time pane snapshot via HERDR_PLUGIN_PANE_THEME_JSON (pane-only; scrubbed from other plugin commands):

• Branch: https://github.com/Akram012388/herdr/tree/feature/plugin-pane-theme
• Commit: akramdotsh@768ba00

It’s a few months behind current master, so treat it as a reference / starting point rather than drop-in. Happy for someone to adapt it; I’m not planning to drive a PR right now.

[gytkk]

I'm using Herdr Annotate with a light terminal theme, and annotation highlights can leave dark text on dark backgrounds. Markdown code text can also appear too bright.

It might be useful to expose Herdr’s resolved theme through a typed PluginTheme struct and serialize it automatically, rather than manually building JSON for each color.
A launch-time snapshot such as HERDR_PLUGIN_THEME_JSON seems sufficient initially. Plugins could map those colors to their UI, while a theme-change event could be added later if live updates are needed.

[ShortArrow]

Another consumer for the resolved palette: hardware.
I'm building a small three-key keypad with an RGB LED under each key that shows herdr agent state (waiting, done, and so on) next to the terminal.
Its colours are hard-coded today, so they stop matching herdr as soon as the theme changes:
herdr draws blocked in the theme's red and done in its teal, and the keypad cannot follow.

https://github.com/ShortArrow/herdr-triton

That consumer differs from plugin panes in two ways:

• It is not a pane. It runs from a startup or event hook, or outside herdr,
  and talks to the socket API, so a launch-time environment value for panes does not reach it.
• It lives as long as the server, so it needs to notice when the palette changes,
  after a config reload or an auto_switch.

A read-only socket query for the resolved palette, with an event when it changes,
would cover plugin panes and devices like this one.
Any LED or LCD gadget will run into the same gap.

One open question is per-client resolution:
with auto_switch or theme = "terminal", two attached clients can resolve different palettes,
so the API would have to say whose palette it returns.

[akramdotsh]

@ShortArrow agreed. A launch-time env value only reaches panes, and it goes stale after a reload or auto_switch, so it can't cover your keypad.

I see the two ideas as layers rather than alternatives:

1. Pane snapshot (what my branch does): HERDR_PLUGIN_PANE_THEME_JSON at launch, so simple popup plugins get themed with no socket client.
2. Socket API (your proposal): a read-only palette query plus a theme_changed event, covering hooks, long-lived processes, and devices.

Both could serialize the same typed PluginTheme, as @gytkk suggested, so there's one shape to maintain.

On "whose palette": the query could take an optional client id, and the response and event could name which client the palette was resolved for.

Happy for a maintainer to say whether layer 1 is a useful first step or whether the socket side should come first.