starplast.slot_tree
A window showing every slot, its place in the tree, and what fills it.
Why this exists
The slot catalog is 222 entries across three hierarchies and two organisms. Every check run on it so
far was a Python one-liner written for the occasion and thrown away -- which is how the first audit
reported a leak that did not exist, because the one-liner reimplemented pattern matching instead of
calling slots.declared_columns.
A sanity check nobody can see is a sanity check nobody performs. This is the audit made permanent and visible: open it and the shape of the whole catalog is in front of you, including the parts that are empty -- which are the most informative parts, and the reason the empty rows are coloured rather than hidden.
The rule this module follows
Nothing here reimplements the catalog. The tree comes from slots.relationship_tree, the columns
from slots.declared_columns, the coverage from slots.resolve, and whether a slot is filled from
slots.is_filled. A second copy of that logic in GUI code is a second thing to keep in step, and it
would not be kept in step -- the window would then disagree with the pipeline while looking
authoritative, which is worse than having no window.
It opens with no data
nodes=None is a supported state, not a degenerate one. This is the tool for inspecting an arm
before its table exists, and a viewer that needs data to show a slot cannot show the arm that most
needs looking at. With no table, coverage is blank and the catalog is still fully browsable.
Every table and graph the catalog is graded against, keyed by organism.
Loaded here rather than taken from the window, because this viewer must be able to show an arm the open window is not displaying -- that is most of its purpose. Missing files are simply absent from the result: an arm that has not been built shows its catalog with no coverage, which is the honest picture and the one instruction 40 asks for.
The four counts this window exists to make impossible to miss.
Computed with the same functions the pipeline uses, so the window cannot report a clean catalog while the build sees a broken one.
The tree, its filters, and the details pane, as one widget so a test can build it headlessly.
Split from the window for the same reason build_preferences is split from open_preferences:
a window that has to be shown to be inspected cannot be tested without a display.
The tree in a window of its own -- shown, never exec'd.
Same rule as Preferences: a modal here would mean checking the catalog against the map from memory, which is exactly the comparison this is for.