: specification

Code: src/spam_gui/modules/<module>/ · Tests: tests/gui/modules/<module>.py, tests/unit/… · Status: draft | in progress | done (SPEC.md section 8 checked)

1. Purpose

• What it does, in one or two sentences, and for whom (e.g., « register two 3D images of the same sample »).
• spam functions called, unchanged (SPEC.md section 1): e.g., spam.DIC.register. The command-line module of spam it corresponds to, if any (e.g., spam-reg), and the conventions taken from it (e.g., which image Φ moves).
• Inputs: the images or files the user gives (types, dimensions, typical sizes).
• Outputs: what the module saves (file names, formats), and what it shows.
• Analysis spam does not have yet (SPEC.md section 1): each function, in src/spam_gui/tospam/<spam package>/ (e.g., tospam/DIC/), and its entry in TO_SPAM.md. None, if possible.

2. Steps

The steps in order, as the buttons of the bar show them. For each one:

Then, per step, what is not obvious from the table: the controls of each sub-pane (with their short labels; details go in tooltips), what is computed and when (at once, on « … », after a short timer), what is shown in the windows (layers, the two images given to windows.setImages), and what makes the step's results out of date (and how that is said, SPEC.md 3.2).

Shared steps used as they are (modules/common/, see specs/common-steps.md): which ones, and with what settings.

Footer (makeFooter), if any: what it shows, whatever the step.

A step shown at any time (anytime = True), if any.

3. State

What the steps share (the module's makeState): each field, which step sets it, which steps read it.

Several binnings, if the module works on large images: which results are kept at each binning, and which are carried to another binning (converted) or made again there, and why (SPEC.md section 5: that choice is the maintainer's).

4. Large images and memory

• What is read by parts, what must be in memory (bytes per voxel), and the message given before a calculation that does not fit.
• What is refused, with the reason given (e.g., a 3D view).
• Scratch files, if any.

5. Decisions

Looks and behaviours agreed with the maintainer, each with its reason. One line each, newest last:

• : . Why: . ()

6. Tests

• Unit tests (tests/unit/…): the non-graphical functions, against spam's own results where possible.
• Window test (tests/gui/modules/<module>.py): its checks, one line each, behaviour and layout (e.g., « step 4 in three numbered panes », « Φ found within half a voxel of the true one »). The images it makes, with a known answer.
• Screenshots (tests/gui/screenshots.py, SPEC.md section 6): each step and each stage the user sees (e.g., before and after a calculation, 2D and 3D), named <command>-<step number>-<step title>[-<variant>].png.

7. Open questions

• …