mesh-catalog/modules/i3status-rust

i3status-rust

The bars as a module (novox/hq ADR 0208, research 026/05).

• Installs i3status-rust, and pacman-contrib for checkupdates, which the update block uses. Claims the mesh's node-bar seat (no verbs yet, ADR 0208 §2). Requires x11-display on its own machine: its bars are i3bar's.
• Owns ~/.config/i3status-rust/, both bars (top-bar.toml, bottom-bar.toml) and their icon set (icons/custom-icons.toml).
• Places the two bar { } blocks as its own i3 drop-in, ~/.config/i3/config.d/60-i3status-rust.conf:
  • the bottom bar shows the machine;
  • the top bar shows the focused window and the tray, on the primary output.
• Places two programs in ~/.local/bin:
  • i3status-updates, the pending-updates block;
  • i3bar-watchdog, which brings back a bar that died.
• Starts the watchdog once per session, from the session's start (the xinitrc slot normal). It ends with the session's own process.

Tools

tool	does
i3status_rust_reload	the running bars re-read their files (i3status-rs restarts in place)
i3status_rust_blocks	each bar's blocks in order, kind and settings, and what each shows now (one run of the bar)
i3status_rust_block_run	one block alone, with the bar's theme and icons, to see what it shows or why it errors
i3status_rust_themes	the themes on the machine and the one each bar uses

The battery, and what else was left out

A bar block that follows one machine's hardware is that machine model's hardware module's (ADR 0208 §1), so the bottom bar here has none:

• the battery, which only the laptop has;
• the GPU, which was the laptop's AMD block, commented out for NVIDIA on the desktop;
• three Bluetooth headsets by hardware address: one person's devices, not the bar's.

i3status-rust reads no drop-in directory, and ADR 0208's slots cover xinitrc and xresources only, so a hardware module has no way into this file yet. Two ways forward, for the operator to choose:

1. Give the bar a slot. A shell-style contribution for: i3status-rust would let the laptop's hardware module add its battery block. That is a decision record of its own, extending ADR 0208 §4.
2. Blocks that show only where they apply. i3status-rust's common if_command option (for example test -d /sys/class/power_supply/BAT0) hides a block on a machine without the hardware. That is "say it by what is there" (ADR 0112), but the knowledge stays in the bar.

Until one of them is chosen, the laptop's bar shows no battery once this module is assigned.

What it improves on what was found

• The weather needs no key. The found block used a weather service with an API key written in plain text in the file, and a fixed city. It now uses the Norwegian Meteorological Institute, which needs no key, located automatically.
• The update count is the module's own, adopted from the operator's ~/scripts/pkg-updates. It counts AUR updates only where an AUR helper is installed. Clicking it lists the updates in the launcher's menu, instead of a theme from a cloned theme repository.
• The faces are JetBrains Mono Nerd Font, not Hack.
• The watchdog is no longer a hand-enabled user unit that ran on one workstation and not the other. It runs on both, once per session, and ends with the session.
• The docker block's click, which ran a program installed on neither machine, is gone.

What it leaves as found

• ~/.config/i3status-rust/scripts/ (a mouse battery script for one device).
• ~/scripts/pkg-updates and ~/scripts/i3-bar-watchdog, replaced here.
• The user unit ~/.config/systemd/user/i3-bar-watchdog.service and its enablement link.

Migration (ADR 0182)

1. Revoke the weather API key that was in the found bottom-bar.toml. It sat in plain text on both workstations. The first push keeps the found file once and then writes the module's, which has no key.
2. Before the first push, on the laptop: systemctl --user disable --now i3-bar-watchdog.service. Otherwise two watchdogs run. Then delete the unit file, ~/scripts/i3-bar-watchdog and ~/scripts/pkg-updates.
3. Until the i3 module carries the main configuration, the found ~/.config/i3/config still has its own two bar { } blocks, and i3 shows four bars. The i3 module's configuration has none.

Blockers

• node-bar, x11-display and the xinitrc slot are ADR 0208's. Until the controller knows them, mctl reads them as unknown.
• The battery block waits for one of the two ways above.
• The watchdog would be a user unit once user-scoped units ship (mesh-host #72). It is not, because it runs per session and ends with the session, as a session-start line already does.
• pacman-contrib is declared here. A future pacman module that wants checkupdates or paccache takes it over, since a package is declared once per node.