Files
DarkRoom/docs
dtourolle a3f3e188e1
Benchmarks / CPU and I/O (per commit) (push) Successful in 1m52s
Benchmarks / Frame budget (on demand) (push) Skipped
Build and test / Desktop (Linux) (push) Successful in 45m4s
Build and test / Layer separation (push) Successful in 41s
Traceability / Requirement traces (push) Successful in 29s
🐳 Android image / Build and push (push) Successful in 1s
Build and test / android-image (push) Successful in 2s
🐳 Windows image / Build and push (push) Successful in 1s
Build and test / windows-image (push) Successful in 1s
Build and test / Android (aarch64) (push) Successful in 29m25s
Build and test / Windows (x86_64, cross) (push) Successful in 34m4s
Build and test / Publish the release (push) Skipped
Move the people tray's ticks in place instead of rebuilding it per press
Filtering the grid by a face crawled on the reference library. The SQL
is not it — the person predicate counts in ~20 ms, the eyes-open term in
~60 — but every press on the tray ran `push_people_chips`, which read the
whole people table (26,362 rows, nearly all empty groups a regrouping
pass left behind) and then called `push_people_roster`, which read it
again and replaced the roster model. The roster is every person holding
a face, 1,581 chips, in a row Slint does not virtualise: a new model
tore down and re-created all of them and laid the row out again, to
move one tick.

A press now walks the roster model and sets `picked` on the rows whose
tick changed; the roster is built only when the tray opens. Both reads
use `people_in_use` (2,140 rows) rather than `people`. A picked person
the in-use query leaves out — emptied by a split while the filter held
them — still gets a chip, since a term with no chip cannot be removed,
and without one the in-place update would fall back to a rebuild on
every press.
2026-09-24 20:21:50 -04:00
..

Documentation

Two audiences, two folders. Most people want the first table and never the second.

Using DarkRoom

The manual Every feature, pictured from the application itself — opening a library, rating and filing, developing, local masks, repair, film, panoramas, export
How it is driven Every gesture and shortcut, by screen. Generated from the code, so it cannot describe one the application does not have

The top-level README says what DarkRoom is, how to get it on each platform, and what is still missing.

Changing DarkRoom

Everything under dev/ is for someone working on the code. Start with CONTRIBUTING.md, which says how to land a first change without reading the rest.

The register and the record. What must be built, how it is built, and how far along it is.

requirements.md What the software must do — the numbered register, the decisions (D-numbers) and the spikes (S-numbers)
architecture.md How it is built — crates, the GPU pipeline, the data model, sync
traceability.md Generated: which requirement is claimed by which file. Never edited by hand
outstanding.md What is specified and not built, and whether that is a decision or a gap
technical-debt.md Compromises taken deliberately, each with the condition that retires it
code-health.md What a contribution costs, per seam, measured

Designs, one per subsystem. Each is the specification the code was built to, kept current as the code moved.

catalog.md The index, the library view, incremental scan, the job queue
storage.md Storage backends: the seam a folder, a sync client and a Nextcloud account share
faces.md Face detection, identity, clustering and the eye-state models
segmentation.md How the application finds the regions a local mask snaps to
mask-editing.md Painting, erasing and combining masks
spot-removal.md Clone and heal as parameters in the edit graph
panorama.md Alignment, projection, the chunked composite and the border fill
inference.md The neural runtime and model chosen per device, with the measurements
display-and-extension.md The display contract, and why the fused pipeline is already most of a plugin format
view-composition.md A controller for the display layer
ui-navigation.md Finding things in the interface once there are many

Measurements. Numbers committed so a regression is a diff rather than a recollection.

benchmarks.md The per-commit suite: what it covers, what it does not, how to read a failure
bench-baseline.json The committed numbers the suite checks against
frame-budget.md What a frame costs on each device, and the decision those figures settled

Platforms and distribution.

distribution.md Which channels v1 targets and what each one constrains
windows.md The Windows installer, cross-built from the Linux CI
android-signing.md Which key signs the APK, and keeping it

Archive. Kept as the record of what was asked for, not as plans.

milestone-v0.1.md The first milestone, delivered 2026-08-30 and superseded
ui-refinement.md How the interface should look; succeeded by ui-navigation.md

Conventions

Two files here are generated and must not be edited by hand: gestures.md and dev/traceability.md. Both come from cargo run -p traceability and the pre-commit hook keeps them in step with the tree. The manual's pictures are recorded by tools/manual and live in LFS.

A design document links to the requirements it satisfies and to the code that satisfies them. When the code moves, the link moves with it; a document that has stopped being true goes to dev/archive/ with a note saying what replaced it, rather than being deleted.