3.2 The terminal workspace
tools/imsisting_tui.py is a full-screen browser in Python's standard library
and nothing else. No ncurses bindings to install, no pip, no dependency that
can be missing on the box you are actually standing next to in a van.
./imsisting.sh --tui
python3 tools/imsisting_tui.py # same program, no launcher
What it knows, and where it learned it
The workspace does not carry its own catalogue. On start it reads:
IMSISTING_MODULE_TABLEout ofimsisting.sh— the categories, the keys and the labels, which is where the numbering on screen comes from;module_index.tsv— each module's verbs, whether it has a selftest, whether it has an info verb;- the window's own source, for the view names each module's page is divided into, and which verbs live in which view.
That third source is what makes the terminal and the window agree about the shape of a module. The alternative — a hand-kept list of views in the TUI — would be a second catalogue, and second catalogues rot. Instead the views you see in the terminal are the views the window draws, read from the same tables.
Three panes
┌ IMSISTING ──────────┬──────────────────────────────────────────────┐
│ CATEGORIES │ MODULES │
│ SYSTEM 5 │ 01 Dependency Manager 9 verbs │
│ RECON 3 │ 02 SDR / Radio Manager 11 verbs │
│ RADIO 14 │ ... │
│ ... │ │
├─────────────────────┴──────────────────────────────────────────────┤
│ SEARCH type to filter modules │
│ ↑↓/jk modules Tab category Shift+Tab pages / search │
│ Enter open ? help q quit │
└────────────────────────────────────────────────────────────────────┘
The left column is the category list with counts, so you can see the shape of the toolkit before choosing anything. The middle column is every module, keyed by its menu number. Opening a module replaces the right-hand side with its description, its views and the actions inside each view.
Keys
| Context | Key | Effect |
|---|---|---|
| Dashboard | ↑ ↓ or j k |
move through modules |
| Dashboard | Tab |
cycle category filter |
| Dashboard | Shift+Tab |
cycle the workspace pages |
| Dashboard | / |
type into SEARCH |
| Dashboard | Enter |
open the highlighted module |
| Dashboard | ? or h |
help |
| Dashboard | q |
quit |
| Workspace | ↑ ↓ |
move through actions |
| Workspace | ← → or [ ] |
previous / next module |
| Workspace | Enter |
run the highlighted action |
| Workspace | a |
give it arguments, then run |
| Workspace | f |
filter the action list |
| Workspace | s |
save the output pane to a file |
| Workspace | c |
clear the output pane |
| Workspace | Esc |
back to the dashboard |
Letters go to SEARCH on the dashboard, which surprises people once: j is a
navigation key only inside a module. Arrow keys are unambiguous in both places.
Arguments are asked for, never guessed
A verb whose usage line reads --since <epoch> cannot be run by pressing
Enter. It opens a line where you type the argument, and the run does not start
until it is given. Nothing in the terminal workspace invents a value for an
argument: a run that would have to guess is a run that would produce a number
you cannot attribute later.
Views the terminal cannot draw
Some views are drawn by the window and have no shell verb behind them at all — the live catcher feeds (§3.3) are the clearest example: they are a widget reading a store every two seconds, not a command. The workspace lists those as
Nodes (in the GUI)
Stream (in the GUI)
rather than omitting them. The view exists; the terminal says so and says where it lives, instead of pretending the module has fewer views than it has.
What it refuses
With no terminal attached — a cron job, a docker run without -t, an editor's
build hook — it prints why and exits non-zero rather than pretending to draw.
That refusal is asserted by tools/check-tui.sh, along with the key uniqueness
that the renumbering above depends on, a real pseudo-terminal render, and the
--help text.