The adjust pass and the readback both scale with pixel count, so a drag
paid full viewport cost on every frame it managed to produce. Halving
each edge while the gesture is moving is roughly a quarter of the work.
Detecting the gesture needed no new plumbing. No control reports a drag
boundary, and threading one out of every slider, curve point and crop
handle would be a lot of surface for what is a rendering concern. The
coalescing flag already carries the answer: a request that arrives while
a render is queued can only come from a control that moved again. A
click, a reset or a resize never coalesces, so those still render sharp
the first time and never show a draft frame.
A settle render restores full resolution 120 ms after the last change —
above the interval between events within a drag, so an ordinary gesture
never trips it mid-motion, and well under the point where waiting for
the sharp frame would be noticeable. Only one settle is ever queued.
The softness is therefore visible only while the image is moving too
fast to study.
dr-ui tests pass.
Every slider, curve-point and crop-handle drag ran a full render
straight from its `moved` handler. A render ends in a blocking GPU
readback, so that stall sat directly on the input path: touch events
arrive far faster than a render completes, the queue backed up, and
positions reached the handlers several samples stale — the jumpy
dragging.
The worse consequence was gestures being lost outright. When events go
unconsumed for long enough Android reclaims the stream and hands it to
the view underneath, so a drag stopped mid-gesture never received `up`,
only `cancel` — which every handler here treats as "abort the drag".
`redraw` no longer renders. It marks the canvas dirty and posts one
render onto the event loop, coalescing any further requests that arrive
while it is pending, and re-checks the flag afterwards so a value that
moved during the render is not left on a stale frame. Handlers now
return immediately, which is what keeps the gesture consumed.
A zero-delay `Timer` rather than `invoke_from_event_loop`: the latter
requires `Send` and this state is deliberately `Rc` on the UI thread.
All existing `redraw` call sites are unchanged — the signature is the
same and coalescing is internal.
Trashing or emptying the trash failed on every scanned image with
"operation unsupported by this backend: fetch by fileid requires a
path".
RemoteId::Stable(oc:fileid) is an identity — it answers whether a file
is the same one after a move, and keys the thumbnail shards. It is not
an address: WebDAV exposes no fileid-addressable endpoint, so the
Nextcloud backend serves get/delete/move_to by path and rejects a bare
Stable. Both trash workers preferred the fileid whenever the catalog
knew one, so the unreachable Path fallback was the only arm that would
have worked, and the failure hit every properly-scanned image rather
than some edge case.
Address by path at both sites, and keep the fileid for what it is for:
the identity MOVE preserves, and the key the thumbnail cleanup uses.
Move::file_id was documented as "the id the MOVE addresses", which is
the wrong claim that seeded this; corrected, along with a note on
RemoteId itself so the distinction is stated where the type is defined.
Only the backend rejection was covered by a test. Added the positive
case, since that contract is what the call sites now depend on. The
workers build their own NextcloudBackend, so no test can reach the
call sites directly — closing that would mean injecting the backend,
which is left alone here.
Verified by build and test; not exercised against a live server.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Two breaks that only appeared on a full `cargo test --workspace`.
`slint::android` exists only when compiling for Android, so darkroom-android
failed to compile on the host even though it is a workspace member. The entry
point is now gated on the target rather than on a feature.
The timeline forwarded `scrub` where the Timeline component declares
`scrub-to`, which the Slint compiler rejects.
Assisted-by: LLM
The UI gains the views the catalog work was building toward: a windowed
library grid with ratings and flags, the collection tree with drag-to-add,
and trash with restore. derived_sync pushes thumbnail shards and the catalog
snapshot to the server's derived folder.
Tokens now have one source of truth. build.rs reads style.yaml and generates
theme.slint into OUT_DIR, which answers every existing
`import { Theme } from "theme.slint"` unchanged, because Slint resolves
imports against the importing file's directory first and the include paths
after. Generating into OUT_DIR rather than beside the hand-written Slint is
the point: a generated file sitting in ui/ looks exactly like the files
around it that are meant to be edited, and an edit to it would survive until
the next touch of style.yaml — a bug that hides for weeks. build.rs fails
loudly if a stale ui/theme.slint exists, which would otherwise shadow the
generated one silently and make every palette change vanish with no error.
The palette moves to near-neutral dark with achromatic signalling, so the
accent means "modified" or "active" rather than "heading". Shared components
land in widgets.slint: a token that binds several values into one concept is
a component, not a row in a YAML file.
Adds an optional live-style feature that makes the tokens in-out so they can
be written at startup — a feature rather than the default because it stops
the properties being constant-folded.
serde_norway is the YAML crate: serde_yaml and serde_yml are both deprecated,
and its mappings preserve insertion order, which is what lets the generated
Slint keep the token ordering the author chose.
Assisted-by: LLM
The picker set loading=true and nothing ever cleared it, because
browser_loaded() was never called — my earlier edit to replace the stub
silently failed to apply after cargo fmt reindented the code it matched
against. The stale stub was still writing folder names into the status
line, which is the list visible under the selector.
Verified by grep before and after: browser_loaded had zero call sites,
now two.
Two related defects fixed while in there. Both timers polled their
channel with `if let Ok(..)`, so a worker thread that died without
sending left the screen on "Loading…" or "Connecting…" forever. Both now
treat Disconnected as terminal.
The first attempt at that fix introduced a bug of its own: a separate
probe call consumed a pending message and discarded it, so a successful
login would have vanished. The login poller now drains in one loop with
disconnection as a match arm, and only reports failure when the flow had
not already completed.
Lesson worth recording: verify a replacement applied rather than trusting
the edit succeeded. A silently-skipped replace looks identical to a
successful one until the feature is used.
43 tests in dr-ui.
It previously fetched the folder list and threw it away into a status
line — a button that looked like it worked and did not. Now it opens a
browsable picker: click a folder to descend, ".." to go back, "Use this
folder" to select, "Cancel" to leave the root unchanged.
Descends one level per click because that is what the backend supports:
Depth: infinity is frequently disabled server-side and prohibitively
expensive where it is not (ARCH §8.4).
The chosen root persists immediately on confirm, so it survives a crash
before the library is opened. Confirming at the account root is allowed —
a user may legitimately keep everything at the top level — and cancelling
leaves any previous selection untouched, which a test asserts.
Verified against nextcloud.tourolle.paris at both depths: 30 folders at
the root, 21 year-folders inside PhotosRaw.
19 launch tests, 38 in dr-ui.
The app now opens on the login screen when there is nothing else to show
— no local paths and no configured library — and goes straight to the
images otherwise. Making someone click past a login they already
completed is pure friction.
launch.slint imported by app.slint, replacing the window rather
than overlaying it: there is no library to look at
until an account is configured
launch_ui.rs the Slint wiring, kept out of lib.rs so the launch
flow can change without touching the develop window
Login runs on a worker thread and posts results back through a channel,
since Slint's event loop is single-threaded and a 20-minute browser wait
cannot block it. The system browser is opened via xdg-open, never an
embedded webview (FR-NC-1).
Sign-out deletes the local credential even if server-side revocation
fails: a network error must not leave a usable secret on the machine.
Format tick-boxes persist on each toggle, so a selection survives a
crash before the library is opened.
Two things deliberately incomplete rather than faked:
- "Choose folder" lists the account's folders and reports them, but
there is no picker widget yet, so selection still happens via the
connect example.
- "Open library" logs the request. Opening a remote library needs the
scan-and-cache path, which belongs with the catalog work in flight.
Earlier I broke the other in-flight dr-ui work by calling
slint_build::compile twice, which replaces the generated module. The
correct wiring is an import inside app.slint, which is what this does.
30 dr-ui tests passing; both launch paths verified by running the app.
Login now persists properly rather than through the JSON file the test
harness was using.
dr-plat SecretStore trait plus a Secret Service backend.
Verified against the live GNOME Keyring: store,
retrieve, delete, confirm-gone all round-trip.
Session/SessionStore splits credentials from settings — the app
password goes to the keyring (FR-NC-2), while
server, login, chosen root and format selection are
ordinary config. A test asserts the credential never
appears in the config file.
LaunchModel the launch-screen state machine, testable without a
display server: sign in, approve in browser, choose
folder, tick formats, sign out.
launch.slint the screen itself, in its own file.
Absence of a secrets daemon is an explicit degraded mode, not a silent
fallback to plaintext — the screen says sign-in will not persist rather
than letting the user find out next launch. Android's Keystore backend
fails loudly for the same reason: a no-op store would look like it
worked and then lose the credential.
Two bugs caught by tests rather than by running it:
- fail() after busy() signed the user out, because busy() had already
discarded the session. A failed *scan* would have logged you out.
Busy now carries the session.
- normalise_server upgrades http:// to https:// rather than accepting
it. NFR-SEC-3 requires TLS, and silently sending a credential in the
clear is not a decision to make on the user's behalf.
launch.slint is not yet wired into app.slint. Calling slint_build::compile
twice replaces the generated module rather than adding to it, which broke
the other in-flight work on dr-ui; I reverted that immediately. Wiring it
needs an import inside app.slint, which is that work's file to change.
419 tests passing across ten crates.
Decode through display, on the GPU: black/white normalisation, Bayer
demosaic, camera colour transform, and the first seven adjustment
operations — white balance, exposure, highlights/shadows, blacks/whites,
brilliance, vibrance, saturation.
Composable shaders. Each operation contributes a WGSL fragment rather
than owning a pass, and dr-pipeline fuses the *active* ones into a single
compute shader. One texture read and one write per frame regardless of
how many adjustments are in play, while the operations stay independent
in Rust — adding one is a new file, with no central shader to edit. An
operation at neutral settings contributes no code, no uniform and no
branch. Uniforms are prefixed per operation so two may both declare
`amount`; helpers dedupe by name from a single source of truth.
Pipelines cache on a structure hash covering the op-set and its order but
not the values, so dragging a slider uploads uniforms and reuses the
compiled pipeline. Measured on a 24 MP CR2: 0.60 ms re-render, one
pipeline compiled across ten slider positions.
The UI is generated, not written. EditGraph::capabilities() reports
parameters with their kinds, ranges, defaults and current values; the
panel builds one control per entry chosen by ParamKind. No file in ui/
names an operation, and dr-pipeline has no wgpu dependency, so codegen is
testable without a device (ARCH §6.5a).
Three defects found against real files, each silent:
- rawler 0.7.2's `xyz_to_cam` is all zeros — deprecated and no longer
populated. The live matrices are in `color_matrix`, keyed by
illuminant. Reading the old field yields no colour transform at all.
- `cam_to_xyz_normalized()` returns all NaN on any Bayer sensor: it
divides each of four rows by its own sum, and the unused fourth
(emerald) row sums to zero. Inverting the 3x3 ourselves avoids it.
`wb_coeffs[3]` is NaN for the same reason and is normalised at decode.
- As-shot white balance reached the uniform block but no shader read it,
so the first render of a real CR2 came out violently green. Green
photosites collect roughly twice the signal of red and blue. Now
applied unconditionally before any operation, with tests on ordering.
Demosaic is Malvar-He-Cutler rather than bilinear: gradient-corrected
interpolation at one 5x5 neighbourhood per pixel, where bilinear leaves
visible zippering on any high-contrast edge at 1:1. Two of the four
packed CFA constants were wrong on the first attempt, so all four layouts
are asserted to reconstruct the same colour. Crop origins at odd
coordinates re-phase the pattern; without that, red and blue swap.
X-Trans reports GpuError::UnsupportedCfa rather than approximating with
the Bayer path, which would look like a corrupt file.
206 tests, including GPU tests proving every operation and the full
seven-operation chain generate compilable WGSL.
Known gaps: the display path still reads back to the CPU each frame,
which ARCH §6.1 forbids and AC-8 asserts against — it is gated behind the
`readback` feature and waits on spike S1 wiring Slint's texture import.
Curve shapes are a first draft and want tuning against real photographs.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Investigated using the Nextcloud desktop client's Virtual Files as a
cache instead of talking to the server directly. Measured on this
machine (client 4.0.7): the configured folder holds 121,785 placeholders
against 10,267 materialised files, including 7,037 CR2 and 9,411 DNG.
Three findings, each independently disqualifying:
- Linux VFS is *suffix* mode. A dehydrated IMG.CR2 exists only as
IMG.CR2.nextcloud holding one byte; the real name is absent.
- Reading a placeholder does not hydrate it. dd of the first 256KB
returned 1 byte, the stub was unchanged, and the real name never
appeared. There is no FUSE layer — the stub is an inert marker.
- Even with hydration the granularity is wrong: VFS has two states,
1 byte or all bytes, and the preview tier needs a ~256KB prefix of
a 27MB file. That is ~100x what FR-NC-3 requires.
Recorded as ARCH §9.0. Coexistence is still supported: dr-types now
recognises *.nextcloud stubs, and the viewer lists them as "not
downloaded" rather than as corrupt files or not at all.
So the connector talks to the server directly, as D7 specified.
Implemented: Login Flow v2, PROPFIND with oc:fileid and nc:has-preview,
ETag pruning via a Depth:0 probe, range GET with local slicing when the
server ignores the header, conditional PUT, and /core/preview with
forceIcon=false. delta() returns Unsupported and says why.
Chunked upload v2 is not implemented yet — put() rejects bodies over
5MB explicitly rather than silently truncating.
Two bugs found by testing: my hand-computed epoch in a date test was a
day out (the parser was right), and quick-xml reaches EOF on truncated
input without erroring, so unbalanced elements needed an explicit check
— a half-parsed multistatus must not look like an empty directory.
83 tests passing.
dr-decode exposes four entry points rather than one decode, because
callers differ sharply in what they need (ARCH §3.2): culling wants a
preview, the grid wants metadata, only develop and export touch sensor
data. Fusing them forces a full decode where a header read suffices,
which is why Lightroom stalls ~2s per image while culling.
Smoke-tested against 1,852 real Canon CR2 files (EOS 6D, ~27MB each):
metadata 0.2ms from a 256KB header read, no full decode
preview ~250ms 5472x3648, downscaled to 2048 for display
jpeg 3.0ms
Two findings worth recording:
rawler 0.7.2's CR2 decoder implements only full_image; thumbnail_image
and preview_image are unimplemented trait defaults returning None. So
every rung of the preview ladder resolves to a full-resolution decode at
~250ms — 5x over NFR-P13's 50ms budget. CR2 does carry smaller IFDs, so
the fix is our own IFD walk or an upstream contribution. The ladder is
written now so that fixing it is a decoder change, not a change to every
caller. Recorded in milestone-v0.1 risks.
Preview.downscale_to bounds memory: a 5472x3648 RGBA preview is 79.8MB,
which exhausts a phone's budget after a handful of images. Box-filtered
so downscaled thumbnails do not alias.
Also fixed a RefCell double-borrow that panicked on first navigation —
`*x.borrow_mut() = *x.borrow() + 1` holds both borrows at once. Verified
with 10,000 programmatic navigations.
58 tests passing. Traceability 20.3% (29/143).
Ports JellyTau's traceability tooling to Rust, carrying across the bug it
was repaired for. That gate divided a traced count by frozen literal
denominators; the requirements file outgrew them and it reported 158%
coverage, so it could never fail its own threshold.
Two rules, both enforced by the extractor's own tests:
- denominators parsed from docs/requirements.md at run time
- coverage is |traced ∩ defined| / |defined|, never a raw traced count
The gate additionally fails hard on a misconfigured run — zero
requirements parsed or zero files scanned — rather than reporting a
plausible 0%, and on any orphan tag naming a requirement that does not
exist.
Adapted for DarkRoom: IDs are FR-CAT-1 / NFR-P13 / FR-DEV-3a shapes
rather than JellyTau's fixed three digits, and decisions (D), spikes (S),
milestone items (M) and test ids remain taggable while being excluded
from the denominator — counting them inflated it by 25.
Also adds dr-sync: the RemoteBackend trait and capability model, so the
Nextcloud connector is one implementation rather than the only shape the
engine understands. No mature Nextcloud crate exists (reqwest_dav is too
thin), so the connector will be hand-rolled over reqwest per D7.
Gitea workflows follow the same style: containerised, commented with the
reasoning, desktop and Android on every push, plus a CI check that no
core/ crate depends on the UI toolkit (ARCH §6.5a).
Coverage today: 13.3% (19/143). 50 tests passing.
Establishes the v0.1 foundations on both platforms:
- dr-types: SourceRef (never a filesystem path — Android SAF has none),
Format, Availability, Validator with ETag quote normalisation
- dr-gpu: wgpu device, compute pass writing a storage texture, resize
- dr-ui: Slint shell with FR-UI-1 adaptive layout, computed in Rust to
avoid a binding loop
- docker/android: pinned toolchain, verified producing API 28 ARM binaries
Measured the cost of the temporary CPU readback path (dr-gpu bench):
compute is 0.06-0.28ms across sizes while readback is 0.63-7.43ms, so
readback is 90-96% of frame time and scales with area. Recorded in
ARCH §6.1 — this is why spike S1 is the priority.
Mitigations pending S1: reuse the staging buffer, apply at most one
resize per frame, and cap render resolution at 2048 on the long edge.
10 tests passing; core crates cross-compile for aarch64-linux-android.
dtourolle
