# rofi

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

- Installs `rofi`, claims the mesh's `node-launcher` seat and serves its verb `menu`. Requires
  `x11-display` on its own machine.
- **A value nobody sees** (`node-launcher.secret`, novox/hq ADR 0259 §10): a prompt that shows nothing of
  what is typed (`rofi -dmenu -password`), whose answer is sealed to the key the asker gives before it
  leaves this process — never in the clear on the bus, in the runtime's log or in a call's record. The
  controller's `give` asks it to take a module's own secret, such as a bot token, at the desk. It waits at
  most 25 seconds. On X11 any program of the operator's account can still read the keys as they are typed
  (ADR 0234's accepted residual risk), so the operator types only into a prompt they started.
- **The seat's dmenu-compatible command.** It places `~/.local/bin/dmenu`: choices on standard input,
  the chosen one on standard output, exit 1 when nothing was chosen. It runs `rofi -dmenu`, passing
  on dmenu's `-p`, `-l` and `-i` and dropping its look options. A script, a notifier or a clipboard
  manager calls `dmenu` and works whichever module holds the seat. On a node where the `dmenu` module
  holds `node-launcher` instead, the real dmenu answers the same calls.
- Owns `~/.config/rofi/config.rasi` and the themes `mesh` and `mesh-powermenu` in
  `~/.config/rofi/themes/`. The faces are JetBrains Mono Nerd Font for the list and the input, and
  Inter for messages. Both are packages of the `fonts` module.
- Places its key bindings as its own i3 drop-in, `~/.config/i3/config.d/50-rofi.conf`. The `i3`
  module's configuration includes that directory after it sets `$mod`.
- Starts nothing. rofi runs when a key is pressed.

| key | runs |
|---|---|
| `$mod+d` | applications (`rofi-launch drun`) |
| `$mod+t` | a command (`rofi-launch run`) |
| `$mod+Shift+t` | a command with sudo, in the terminal (`rofi-launch sudo`) |
| `$mod+Shift+w` | the window switcher (`rofi-launch window`) |
| `$mod+Escape` | the power menu (`rofi-powermenu`) |

## The power menu is here

The power menu belongs to the session. It is still the launcher's, because all of it is rofi: its
theme, its buttons and its confirmation. Every action it takes is a verb of logind or the service
manager, so it names no window manager and no locker:

- **lock** is `loginctl lock-session`, which the holder of `node-lock-screen` answers;
- **log out** is `loginctl terminate-session`;
- **suspend, reboot and shut down** are `systemctl`'s.

A Wayland session gets the same menu from whichever launcher holds the seat there.

## Tools

| tool | does |
|---|---|
| `node-launcher.menu` | show a list in the operator's session and answer the chosen line and its index, or `cancelled` (also when nobody answers within the timeout, 20 s by default, 25 s at most) |
| `rofi_applications` | the desktop entries the launcher offers, the account's own winning an id; filter by words, hidden ones on request |
| `rofi_themes` | every theme (the mesh's, the account's, the distribution's) and the one configured |
| `rofi_run` | start a desktop entry or a command in the session, under the account's service manager |

## What it improves on what was found

- **Plain `dmenu` calls work again.** The one found on 2026-10-04 is the notifier's context menu: on
  both workstations it called `/usr/bin/dmenu`, which neither had installed. The `dunst` module now
  calls `dmenu`, and this module answers it. The operator's own scripts all call `rofi -dmenu`, which
  keeps working.
- **The theme is one file per face.** There is no colour file imported from a cloned theme
  repository. The faces are the decided ones (research 026/04): Iosevka and Hack are gone.
- **The retry after resume no longer reopens a closed menu.** The found launchers retried
  `rofi -dmenu` on any failure, so pressing Escape in the sudo prompt reopened it four times.
  `rofi-launch` retries only a failure within half a second, which is a failed keyboard grab.
- **The power menu locks through logind,** so it goes through the one locker. The found one ran
  `i3lock` directly and bypassed it. Log out no longer names four window managers.
- `icon-theme` and `window-command` are gone. They named an icon theme and a program (`wmctrl`) that
  nothing installs. rofi's defaults serve.

## What it leaves as found

- `~/.config/rofi/themes-repo/` (a cloned theme repository), the five symbolic links into it
  (`applets`, `images`, `launchers`, `powermenu`, `scripts`), `colors/`, `theme.rasi` and
  `powermenu.rasi`.
- The predecessor's scripts in `~/scripts`: `rofi-launcher-normal`, `rofi-launcher-terminal`,
  `rofi-launcher-terminal-sudo` and `powermenu` (replaced here), and `theme-picker` with its modes
  (settings, once issue 168 closes).

## Migration (ADR 0182)

Once the `i3` module carries the main i3 configuration:

1. Delete `~/.config/rofi/theme.rasi`, `powermenu.rasi`, `colors/`, the five links and `themes-repo/`.
   Nothing reads them any more.
2. Delete the four scripts above from `~/scripts`.
3. Your scripts that call `rofi -dmenu` keep working. Calling `dmenu` instead lets them follow the
   seat, for example to a Wayland launcher later.

## Blockers

- `node-launcher`, `x11-display` and the `i3` drop-in directory are ADR 0208's and the `i3`
  module's. Until the controller knows the seat, `mctl` reads the claim as unknown.
- `~/.local/bin` is on `PATH` through the `zsh` module's environment contribution (ADR 0203). The
  key bindings name `~/.local/bin/…` in full, so they do not depend on it. Callers of `dmenu` do.

## Its i3 lines are a contribution (changed 2026-10-05, novox/hq ADR 0212)

The module no longer writes a file into i3's `config.d`. Its window-manager lines (the source is still
under `files/i3/` where it had one) are a contribution to `node-display-session`. The i3 module places
them in its own configuration under a `# <module>` line, so this module depends on a window manager
being assigned beside it.