processes: a window on what the machine is running -- every process
from process 1 down, each under the one that started it, with its
share of a processor and the memory it holds as bars, and a row along
the top with the machine's own two bars. The shape
of a process viewer (top, htop, the task manager) cut down to looking,
plus one key that changes the machine: delete, which asks before a
process is ended. A program in a repository of its own, built against
the libraries beside it -- ../canvas for drawing, ../look for the theme,
../toolkit for the parts (the table is its) and the run loop -- the way
any program with a window is meant to be.

  processes.talc        the program: the totals row with its bars and
                        the List button, the table in a frame; the
                        readings of /proc and /sys; the tree folded and
                        unfolded, or flattened; what a press and the
                        keys do; the popups: a process's details, the
                        question before a process is ended, a refusal
  examples/machine/     a frozen machine written by hand -- a dozen
                        processes' /proc, its meminfo and iomem, and a
                        card's /sys -- that the regress shows, so that
                        its pictures never change
  examples/drive.talc   what the regress plays at it: the first reading,
                        the screen's row pressed and pressed again for
                        its details, ctrl+k, the CPU heading pressed
                        twice, delete and shift+delete for the
                        questions, return (refused under -root), delete
                        on process 1, the screen's marker pressed and
                        the keys for folding, ctrl+t for the list,
                        ctrl+m for the memory
  examples/drive-classic.talc   two steps again, in the classic look
  examples/*.ppm        the pictures expected at each step
  scripts/build.sh      builds processes.talc into bin/processes
  scripts/regress.sh    runs it under ../screen with no card on
                        examples/machine, twice (the built-in look, the
                        classic one), and compares the pictures

Build:

  scripts/build.sh
  scripts/regress.sh

which need the installed toolchain (compiler on PATH), ../canvas built
(its fonts), ../look (its example themes and its icons), ../toolkit,
and for the regress ../screen built. Start it from the launcher
(`processes`) or the screen's -run; ../vm/scripts/build.sh puts it at
/bin/processes in the machine.

  processes [-font <name>] [-every <milliseconds>] [-root <directory>]

Reads the machine's /proc and /sys every two seconds (-every for
another interval) and fills the table. The table is drawn in dina-13,
the monospaced bitmap face the terminal and the editor write in, so
that the digits of a column line up, or in the theme's font where that
font is not there, unless -font names another. -root reads
<directory>/proc and <directory>/sys instead of the machine's, which
is how the regress plays a frozen machine; nothing under -root is
signalled. The window begins at 72 by 24 cells of the theme's font and
follows the screen from then on.

THE WINDOW. Along the top the machine as two bars: how many processors
and how busy they are, and RAM used of RAM the kernel has (MemTotal
less MemAvailable, of MemTotal), each a bar filled that far with the
number over it, and at the right the button that shows the processes
as a list (List) or as the tree again (Tree). A press on the RAM bar
(or ctrl+m) opens THE MEMORY in a window of its own, names down the
left and what they are beside them: what the machine declares
(the System RAM of /proc/iomem, readable as root, so on the talc
machine) and what the kernel has of it, the rest being its own image
and reservations; what is in use broken down from /proc/meminfo into
programs' own pages (AnonPages), files held in RAM and shared memory
(Unevictable, which is the root filesystem unpacked from the
initramfs, and Shmem, tmpfs and the card's buffers), the kernel's own
(slab it cannot give back, stacks, page tables) and whatever is left
(drivers, reserved pages); then what can be given back (page cache
and reclaimable slab, which the kernel counts as available) and what
is free. Beside the programs' own pages it says what the rows add up
to, which counts a mapped file and a shared page once for every
process that has it, and so comes out larger. Under it the table,
taking the height: PID; Name, the process's own (comm, cut to 15 bytes
as every viewer shows it), indented two spaces for each level of the
tree, with a marker before a process that has children ("-" when they
are shown, "+" when folded away) and " (ended)" after one that has
ended and not yet been collected by its parent; CPU, a bar of the
process's user and system time since the last reading as a share of
one processor, the number to one decimal over it (the first reading
shows its share since it began, as ps does); RAM, a bar of what it has
resident as a share of the machine's memory, the amount over it. A bar
is green under half, amber to four fifths, red past that, and its text
is in ink on every row, the chosen one too. Children follow their
parent in PID order. Kernel threads (process 2 and everything under
it) are left out until ctrl+k shows them; a process's details say how
many.

A PRESS on a row chooses it. A press on the chosen row again (or
return, with the focus in the table, which has it when the window
opens) opens its DETAILS in a window of its own, titled with its name
and PID, the way the system properties opens a device's: names down
the left and what they are beside them -- its state (running,
sleeping, ended and not yet collected...), what started it, its
command line, or "(the kernel's)" for a kernel thread, how long it
has run, its CPU time and its share now, its RAM, what this viewer
sent it, if anything, and how many processes are shown and kernel
threads hidden -- set again at every reading. Escape in it or its
close button closes it; several may stand at once, and they are
dragged about like any window. A press on a heading
sorts by that column, numbers descending and names ascending; a second
press on the same heading turns the order over. In the tree siblings
are sorted under their parent, each child still under it; in the list
everything is sorted together. The chosen process is kept by its PID
across readings, so it stays chosen as processes above it come and go.

FOLDING. A press on the marker before a name folds that process's
children away, and unfolds them again; so do left and right on the
chosen row, and left on a row with nothing to fold moves the choice to
its parent, right on a folded row unfolds it and on an unfolded one
moves to its first child. The folded set is kept by PID across
readings, so what was folded stays folded as the readings come.

THE LIST. Ctrl+t, or the button along the top, shows every process in
one level, in the sort column's order over all of them, with no
markers; ctrl+t or the button again shows the tree. Kernel threads are
hidden or shown the same either way.

ENDING A PROCESS. Delete asks, in a popup in the middle of the window,
to end the chosen process: "End sleep 4711?" with End and Keep it;
return answers End and escape Keep it, as does a press anywhere
outside the popup. End sends terminate (signal 15), which the process
may catch to finish what it is doing. Shift+delete asks to kill it
instead (signal 9, which it cannot catch), and so does delete on a
process this viewer already asked to end and that is still here. When
the kernel took the signal the table is read again at once and the
process's details say so from then on ("From here: asked to end"); when
it refused ("operation not permitted" for another user's process) a
popup of one line says so, and the details keep that too. Process 1
and the kernel's threads are refused before asking, in such a popup.

THE KEYS. Up and down move the choice, page up and page down a page;
return opens the chosen process's details; left and right fold and
unfold its children (left on a row with nothing to fold goes to its
parent); delete asks to end the chosen process and shift+delete to
kill it; return and escape answer the question, or close a refusal;
escape in a details or memory window closes it;
ctrl+k shows the kernel threads, and hides them again; ctrl+t shows
the list, and the tree again; ctrl+m opens the memory; F5 reads again
now; tab moves the focus between the table and the button.

Exit codes: 0 the window was closed; 1 the screen or the font refused
something; 2 the arguments were wrong.

WHAT THE TREE SHOWS OF THE LAUNCHER. The launcher starts the program
typed into it and ends; the screen collects it and takes in the
program it left behind (the screen adopts what its programs leave),
so a program started from the launcher sits under
the screen in this tree like one the screen started itself, and no
launcher row lingers as "(ended)".

NOT HERE: the card's memory (a VRAM column read from fdinfo); changing a priority, a signal other than terminate and kill,
ending a whole subtree, a menu on a row; columns for state, threads,
user, priority, GPU time; a per-thread view; tree lines instead of
indentation, a search, pausing; a graph.