Adopt Rex in place of herdr, and its session/window/block model for the desktop #4

Open
opened 2026-10-10 23:53:23 +02:00 by arne · 0 comments
Owner

This was generated by AI during triage.

Triage: enhancement, needs-triage. Blocked: Rex isn't released for Linux yet. Its public beta is macOS-only; the docs say Linux servers and clients exist but aren't in testing.

Decision

Superlogical's Rex will replace herdr, and fjordxy will be built around it. Every docs page is also available as markdown by adding .md to its address.

Rex's terms as fjordxy's terms

Rex organises work as session → window → block: a session is a group of related work, a window is a tab holding a layout of blocks, and a block is one application (today, a terminal). Every one has a stable id and an optional label.

Proposal: fjordxy uses the same model for the desktop as a whole.

Rex fjordxy / niri today Proposed meaning in fjordxy
session workspace ("desktop") A desktop: one row of the vertical stack
block window One thing on a desktop: a terminal or a GUI app
window — ? (see below)

The point is that a terminal running inside Rex and a GUI app managed by niri are the same kind of thing (a block in a session), so features like the window overview (#3) can treat them uniformly.

Open questions on the terminology:

  • "Window" would mean two different things. In Rex it's a tab holding a layout of blocks. In niri, and in everyday speech, it's an app window. Does fjordxy have a level that corresponds to Rex's window? A niri column (which holds stacked windows) is the closest structural match, but it isn't a tab. Or is that level simply skipped on the desktop side?
  • Is a whole Rex session one block on the desktop, or is each Rex block a desktop block? In other words: does a terminal window showing a Rex session count as one thing, or does it expand into the blocks inside it?
  • Do Rex sessions and fjordxy desktops line up one to one? For example, opening the "build" desktop would attach the "build" Rex session. Or are they independent?
  • Where the vocabulary gets written down (a glossary in PLAN.md or a new CONTEXT.md) so code, docs and UI use the same words.

What Rex gives fjordxy (from the docs, not yet verified)

  • An event stream: rex events --all --json prints one JSON object per line, the same shape as niri's. A Rex.qml singleton could mirror Niri.qml.
  • Per block: terminal.process_changed (foreground process name, cwd, pid), pwd_changed, title_changed and child_exited.
  • Program status: OSC 7501 records arrive as program_status_changed and program_status_removed events, with states idle / working / done / blocked (permission, question, auth) / error, plus msg and progress.
  • Screen read: com.superlogical.terminal.format.
  • A self-describing API: rex api list and rex api describe (--json returns the schemas). Scripting is in Lua with rex do.

herdr touchpoints to replace

  • the flake input: flake.nix:31-39, plus the herdr argument threaded through hm-module.nix, nixos.nix and options.nix
  • the package option: nix/options.nix:635
  • the palette mapping: nix/herdr-config.nix and nix/experience-home.nix:228-241
  • the system package: nix/nixos.nix:122
  • milestone M22 and the herdr notes in PLAN.md

Questions to answer once Rex ships for Linux

  1. The client model. Is the Linux client its own app with its own app_id, or does it run inside Ghostty? How do you get from a niri window to a Rex session, window or block? (#3 depends on this.)
  2. Theming. Can Rex take fjordxy's palette, the way herdr-config.nix does for herdr? Rex is configured in Lua (~/.config/rex/init.lua).
  3. Packaging. Can it be pinned in the flake like herdr is? What's the licence and how is it distributed?
  4. The server. Should the Rex server run as a user systemd unit?
> *This was generated by AI during triage.* **Triage:** enhancement, needs-triage. **Blocked:** Rex isn't released for Linux yet. Its public beta is macOS-only; the docs say Linux servers and clients exist but aren't in testing. ## Decision Superlogical's [Rex](https://www.superlogical.com/rex/docs) will replace herdr, and fjordxy will be built around it. Every docs page is also available as markdown by adding `.md` to its address. ## Rex's terms as fjordxy's terms Rex organises work as **session → window → block**: a session is a group of related work, a window is a tab holding a layout of blocks, and a block is one application (today, a terminal). Every one has a stable id and an optional label. Proposal: fjordxy uses the same model for the desktop as a whole. | Rex | fjordxy / niri today | Proposed meaning in fjordxy | | --- | --- | --- | | session | workspace ("desktop") | A desktop: one row of the vertical stack | | block | window | One thing on a desktop: a terminal *or* a GUI app | | window | — | ? (see below) | The point is that a terminal running inside Rex and a GUI app managed by niri are the same kind of thing (a block in a session), so features like the window overview (#3) can treat them uniformly. **Open questions on the terminology:** - **"Window" would mean two different things.** In Rex it's a tab holding a layout of blocks. In niri, and in everyday speech, it's an app window. Does fjordxy have a level that corresponds to Rex's window? A niri column (which holds stacked windows) is the closest structural match, but it isn't a tab. Or is that level simply skipped on the desktop side? - **Is a whole Rex session one block on the desktop, or is each Rex block a desktop block?** In other words: does a terminal window showing a Rex session count as one thing, or does it expand into the blocks inside it? - **Do Rex sessions and fjordxy desktops line up one to one?** For example, opening the "build" desktop would attach the "build" Rex session. Or are they independent? - Where the vocabulary gets written down (a glossary in PLAN.md or a new CONTEXT.md) so code, docs and UI use the same words. ## What Rex gives fjordxy (from the docs, not yet verified) - **An event stream:** `rex events --all --json` prints one JSON object per line, the same shape as niri's. A `Rex.qml` singleton could mirror `Niri.qml`. - **Per block:** `terminal.process_changed` (foreground process `name`, `cwd`, `pid`), `pwd_changed`, `title_changed` and `child_exited`. - **Program status:** [OSC 7501](https://www.superlogical.com/rex/docs/build/program-status) records arrive as `program_status_changed` and `program_status_removed` events, with states idle / working / done / blocked (permission, question, auth) / error, plus `msg` and `progress`. - **Screen read:** `com.superlogical.terminal.format`. - **A self-describing API:** `rex api list` and `rex api describe` (`--json` returns the schemas). Scripting is in Lua with `rex do`. ## herdr touchpoints to replace - the flake input: `flake.nix:31-39`, plus the `herdr` argument threaded through `hm-module.nix`, `nixos.nix` and `options.nix` - the package option: `nix/options.nix:635` - the palette mapping: `nix/herdr-config.nix` and `nix/experience-home.nix:228-241` - the system package: `nix/nixos.nix:122` - milestone M22 and the herdr notes in `PLAN.md` ## Questions to answer once Rex ships for Linux 1. **The client model.** Is the Linux client its own app with its own `app_id`, or does it run inside Ghostty? How do you get from a niri window to a Rex session, window or block? (#3 depends on this.) 2. **Theming.** Can Rex take fjordxy's palette, the way `herdr-config.nix` does for herdr? Rex is configured in Lua (`~/.config/rex/init.lua`). 3. **Packaging.** Can it be pinned in the flake like herdr is? What's the licence and how is it distributed? 4. **The server.** Should the Rex server run as a user systemd unit?
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
bases/fjord#4
No description provided.