Manage Plugins at Runtime

[annikahannig]

Would sometimes be super handy I guess.

Maybe we need some kind of control center or something lol.

[vibechoom]

Triage

What it asks

An in-shell way to manage plugins at runtime — @annikahannig's "control center" — instead of today's edit-a-systemd-unit-and-restart flow.

How plugins work today (the constraint)

• The host is transport-only. trollshell/src/plugins.rs:6-8: "Supervision is systemd's job — a crash is just a disconnect. This module is the transport only: it does not spawn or supervise plugins." Plugins are systemd user units (crates/hytte-plugin-proto/src/lib.rs:26) — trollshell-plugin-{pet,weather,departures,clock-demo}.service — that dial plugin.sock and self-identify via PluginMsg::Register.
• The host does keep a live registry of connected plugins: per-connection generation tokens + region mailboxes (plugins.rs:129-150), so it already knows which plugins are connected, what they're rendering, and into which mount region.
• In-shell lifecycle control = none today. crates/hytte-services/src/systemd.rs talks to systemd but read-only — failed_units() only, no StartUnit/StopUnit.
• No declarative registration either: nix/*.nix expose enable/package/weather.*/wallpaper.*, but no programs.trollshell.plugins.

Severity

Severity: low — quality-of-life; nothing's broken, the systemd flow works.

What "manage at runtime" could concretely be — three tiers

1. Status dashboard (read-only). A "Plugins" drawer page listing each plugin: connected/rendering (from the host registry) vs its systemd unit state (active / failed / disabled). Cheapest — needs the host to expose its live registry as a signal + enumerate trollshell-plugin-* units. No write path.
2. On/off toggles. Tier 1 + a switch per plugin that starts/stops its systemd user unit live. Needs systemd.rs to grow StartUnit/StopUnit (+ Enable/DisableUnitFiles for persistence) via the systemd D-Bus manager through hytte-bus (it only reads today).
3. Full dynamic add/remove/configure. Drop in a new plugin + config with no nix rebuild — wants the missing programs.trollshell.plugins nix option as its declarative half plus a runtime register-a-unit path. Biggest.

Recommendation

A "Plugins" control-center drawer Page, tier 1 → tier 2: live status list first (a clean, small first PR that just surfaces the registry + unit state), then per-plugin on/off backed by systemd start/stop. It's also the natural home for the plugin-health that #344 (hyperhive) and #320 (usage) would otherwise each reinvent, and it pairs with the declarative-registration nix option as the runtime counterpart.

The call

@annikahannig — which tier is the "control center" you're picturing?

1. read-only status dashboard,
2. on/off toggles (start/stop units live), or
3. full dynamic add/remove?

And where — a dedicated drawer Page, or a section in an existing panel? That sizes it: tier 1 is small, tier 3 is a project. (Tier 1+2 is my recommendation for a first cut.)

[kaesaecracker]

i assume unloading at runtime is out of scope, this is about everything needed to drop an out of tree plugin in the nix config without having to recompile everything. or is that something else @annikahannig?

[vibechoom]

@kaesaecracker good reframe — and one technical premise worth correcting: the shell already doesn't recompile for a plugin. Plugins are out-of-process binaries that dial plugin.sock and self-identify via PluginMsg::Register (the hytte-plugin SDK; trollshell/src/plugins.rs:6-8 — the host "does not spawn or supervise plugins"). The out-of-tree vibectl widget already builds independently and just tracks trollshell main. So "drop in a plugin without recompiling everything" is already true for the plugin binary itself.

The missing piece is exactly the declarative glue: there's no programs.trollshell.plugins = [ … ] nix option to register a plugin's systemd user unit + socket wiring — nix/{module-common,hm-module,nixos-module}.nix only expose enable/package/weather.*/wallpaper.*, and the bundled plugins' units aren't module-wired. (That's tier 3 in my triage above, and the same gap #344 ran into.)

So if #348 is scoped as "a declarative programs.trollshell.plugins nix option that emits the unit(s) for an out-of-tree plugin package (no runtime load/unload)", that's a clean, well-bounded, buildable feature — a home-manager/nixos option taking { package; args?; mount?; } entries and generating each systemd.user.services.trollshell-plugin-<id> (mirroring the hand-written etc/systemd/user/trollshell-plugin-pet.service). It also unblocks #344.

@annikahannig — confirm that's the scope (declarative nix drop-in, runtime unload out of scope) and I'll build it.

[kaesaecracker]

@vibechoom i think that is a different issue after all. pls make the described scope a new issue and go for impl 🚀

[vibechoom]

Done — split the declarative-nix-drop-in scope out to #350 (kept #348 for the runtime-management/control-center angle). Building #350 now: a programs.trollshell.plugins home-manager option that emits a trollshell-plugin-<id> user service per entry. 🚀

[annikahannig]

Plugin app should live outside shell. (typ gnome control center)

Could be worth dedicated issue.

[vibechoom]

@annikahannig — got it: the runtime plugin-management UI lives outside the shell, gnome-control-center-style (a separate companion app that talks to trollshell, not an in-shell drawer). Clean split — and it's the natural home for the settings surfaces coming out of #375 too (displays, appearance…), so trollshell grows one external "control-center" companion instead of N in-shell panels.

Before I file: do you want this as its own dedicated issue — "trollshell control-center: external settings + plugin-management app", with this #348 becoming a consumer of it — or keep it as #348's scope and just record the out-of-shell decision here? Say the word and I'll file it.

[annikahannig]

besides plugin management the other things that could be handy is

• place / geolocation management
• Ai api key management

[vibechoom]

Captured the whole shape as #381 (trollshell control-center: external, out-of-shell settings + management app). Folded in your new scope — plugins (this issue) + place / geolocation + AI API key management — with #348 becoming the Plugins tab and #381 the umbrella.

Left two things open on #381 for you: the transport (a cc.hannig.trollshell.Control D-Bus interface is my default guess) and "anything else it should own" (display mgmt from #375, appearance/accent from #376?). 🎛️