8 Commits

Include renames

Author	SHA1	Message	Date
dtourolle	f12aece07e	Make storage pluggable, and prove it with a folder backend ... `RemoteBackend` existed from the first release and bought nothing it was designed for. Seven files in `dr-ui` constructed a `NextcloudBackend` directly, an account *was* a server URL beside a DAV user id, the local cache directory was named after a hostname, and the launch screen knew that signing in meant a browser handshake. The trait was real; the seam was documentation. A trait over operations is only a quarter of it. Pluggable storage needs four things, and this adds the other three: - **Capabilities** — already there, and the reason the engine can drive two backends at the speed each actually runs at. - **Configuration** — `dr_sync::Account`: where a library lives, in whatever form its connector addresses, with no server in it. Loads every existing config unchanged (`backend` defaults to `nextcloud`, `endpoint` is stored under its historical `server` key), and `Account::namespace()` reproduces the old catalog directory byte for byte, because changing it would abandon a catalog, its thumbnail shards, and the sidecars holding unsynced offline work. - **Registration** — `BackendProvider` and `BackendRegistry`. `ui/dr-ui/src/remote.rs` is now the only file above `dr-sync` that names a connector. `Connection` (an account plus an optional `Secret`) replaces the credentials-and-user-id pair that was threaded through fifteen signatures in an order that could be swapped. `Secret`'s inner string is reachable only through `expose()` and its `Debug` prints `Secret(***)`, so the indirect leak — a `{:?}` on anything holding one — no longer compiles into a leak. Nextcloud is unchanged and keeps every peculiarity: propagating ETags, chunked upload v2, `oc:fileid`, the `oc:permissions` probe on a refused PUT, the 423 retry classification, Login Flow v2. Those are what the capability model exists to serve, not something to hide. `dr-sync-folder` is the second connector: a local disk, a network mount, an external drive, or a folder a Nextcloud client already syncs. No account, no credential — the route that works where no secrets daemon does. It declares `LocalEtags` rather than claiming propagation a POSIX directory cannot provide, which costs nothing because 50k `stat` calls are not 50k PROPFINDs. Identity is a path hash, not an inode: an inode survives a rename but differs between devices and is reused after a delete, so two machines would disagree about which photograph a thumbnail belonged to. Re-deriving a thumbnail is a cost; showing the wrong one is a bug. docs/storage.md is the contract — the traits, the four steps to add a backend, and what each connector declares. ARCH §8.0 and §8.4a, and FR-NC-13, say why.	2026-08-29 09:57:52 +02:00
dtourolleandClaude Opus 5	242374fd0f	Let the interface hold a backend without knowing whose it is ... `dr-sync` defines `RemoteBackend` and a capability model the engine adapts to, so a second backend can be added without touching the code that uses one. That boundary was documentation. Seven files in `dr-ui` constructed a `NextcloudBackend` directly, ten functions took one by concrete type, and exactly two call sites in the tree — both inside `dr-sync` itself — ever held the trait object. A WebDAV or local-folder backend would have had a well-written trait to implement and nowhere to go afterwards. The change is smaller than the finding suggests, because the trait was already right. Every method the UI has ever called on a backend — `get`, `put`, `list`, `delete`, `create_dir`, `move_to` — was already on it, so nothing had to be added and no behaviour moved. Ten signatures widened to `&dyn RemoteBackend`, sixteen constructions became `remote::connect`, and `remote.rs` is now the only file in the interface that names a connector. `connect` returns `Result<Box<dyn RemoteBackend>, RemoteError>`. The error type is `dr-sync`'s rather than the connector's, which is why every call site kept its shape — the `match`, the `let Ok(..) else`, and `.map_err(ScanFailure::local)?` all still read as they did. One wrinkle worth recording: `&Box<dyn Trait>` does not reach `&dyn Trait` on its own. The compiler reaches for unsizing, which wants `Box<dyn RemoteBackend>: RemoteBackend`, and reports a confusing missing impl rather than suggesting a deref. Twelve call sites therefore say `&*backend`, and two say `let backend: &dyn RemoteBackend = &*backend` where a borrow is shared across lanes. What this does *not* do is abstract credentials. `AppCredentials` is an app password from Login Flow v2 — a Nextcloud protocol, not a general notion of authenticating to a remote — and seven files still name it. An OAuth token, a bucket key pair and an app password have no useful common shape, so deciding what an account is across backends before a second one exists would be a confident guess. code-health.md CH-2 now records that as the remaining half, and it should wait for the backend that forces it. Verified: fmt clean, clippy clean at -D warnings, 2041 tests pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-27 19:51:23 +02:00
dtourolleandClaude Opus 5	56978fdf35	Clear the clippy warnings that were failing CI before this branch ... Nothing here is film simulation. These are lints that fail master today, under the -D warnings CI runs with, mostly from a toolchain that learned new ones rather than from anybody's code -- `is_multiple_of` and the derivable `Default` did not exist as lints when this was written. They are fixed rather than allowed, and by hand rather than by trusting `cargo clippy --fix` wholesale: its automatic pass split a derive in two and left a stray blank line, which is the sort of thing that is correct and still wrong to commit. The four that needed a decision rather than a rewrite: - The distance transform's inner loop writes through its iterator now. `q` stays, because it is the position the parabola is evaluated at as well as the index it is written to -- the lint is about the write. - `to_source` and `to_proto` take `self` by value. Their receiver is `Copy`, so this is the same machine code and the honest signature. - The export path's return type is five levels deep and now has a name, plus a line saying why the `Option` wraps the `Result`: `None` is cancellation, which is not a failure and has no error to report. - A test fills a range instead of looping over one. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-25 22:35:02 +02:00
dtourolleandClaude Opus 5	59362fcecf	Let the copyright survive the export, and the GPS not ... Carries the source's metadata all the way to the file the user hands over, and proves in bytes that the coordinates do not come with it. The privacy test was the piece that mattered and the piece that was wrong. It searched the whole file for the two-byte hemisphere reference "N\0" or "E\0", which is not a fingerprint of a GPS directory at all: sample 14 of the sRGB tone curve inside the ICC profile every export embeds is 69, written as `00 45`, and the next sample is below 256, so its high byte is `00`. Every format would have failed a test about a colour profile. The needle is now the twenty-four bytes a coordinate actually serialises to — three rationals, both byte orders, since exif.rs writes little-endian and the tiff crate writes in the host's — which cannot match by accident, and the retaining test asserts the same needle is *present* so a search that could never find anything cannot make the stripping test pass by being useless. The batch exporter now hands the decoder's reading on to the encoder. It already read the metadata for the orientation and the {date} token; passing it through is what puts the camera, the lens and the rights statement into the file. Nothing about privacy is decided there — dr-export takes that decision once, from the settings. The example passes it too, because it is the only place in the tree that produces files a person can open in exiftool. A unit test can prove a GPS directory is absent from a byte slice; only a real export proves a real photograph comes out the far end still knowing which camera took it. TRACES: FR-EXP-8 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-22 19:15:06 +02:00
dtourolleandClaude Opus 5	44f0a4971b	Show the folder picker on the platform that needs it most, and upload at once ... Two faults, both of my own making, reported from the tablet as "I cannot select a location" and "it does not upload". **The picker button was gated on `target-selected == 1`.** That index was Remote's position while both targets were offered. Making the target list platform-aware narrowed Android's to Remote alone, so Remote became index 0 and the button disappeared — on the one platform where the picker is the *only* way to set a destination, since a device folder is not reachable there at all. It is gated on a boolean derived from the target now. An index into a list whose length varies is not a fact about the target, and writing it as one is what made a correct change break the thing it was meant to fix. **A queued export waited for a sync pass.** Staging first is deliberate — an export is finished on disk the moment it is written, and offline is then just a longer queue — but nothing drained the outbox until the next sync, so "Queued for Exports" sat unchanged and read, fairly, as an upload that never happened. A finished batch that wrote anything now drains immediately. The sync-pass drain stays: the first makes an upload feel immediate, the second is what eventually delivers the exports made in a tunnel. Committed without the parallel session's in-flight collection work, which is mid-save and does not compile; verified by stashing it and building this tree alone. 281 dr-ui tests pass, clippy clean. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-17 12:01:12 +02:00
dtourolleandClaude Opus 5	a8b28136a6	Merge the batch export, and settle the seven-branch merge ... Resolves the last of the parallel work. Two conflicts worth recording, because both were semantic rather than textual: `render_for_export` gained a colour space on master while the batch branch was rewriting the single-image export path around it. Kept both: the batch request supersedes the synchronous path, and the space still has to be chosen at render time because the conversion happens in the shader before the clip to 0..1. `render_open_frame` takes it as an argument rather than reaching for a controller it does not hold. The map-wait moved into `readback::await_mapping` on one branch while another was editing the constant it used, so `READBACK_POLL_LIMIT` survived the merge with no callers. Removed rather than left for clippy to find later. 1164 tests pass, clippy clean, fmt clean. Traceability 53.0% -> 54.3%. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-17 10:11:44 +02:00
dtourolleandClaude Opus 5	7d3c8c521f	Export a whole selection, on a thread that is not the interface's ... The export button rendered, resampled and encoded a 24 MP frame on the UI thread and the window was dead for all of it. That was written down as a known compromise, on the grounds that a batch is what makes the wait intolerable rather than merely noticeable. This is the batch, so the compromise comes due. The grid's selection now exports (FR-EXP-7). A worker thread takes a clone of the `GpuContext` — an `Arc` pair over a device and a queue — and opens each photograph for itself: fetch, sidecar, decode, demosaic, render at full size, resample, sharpen, encode, write. Nothing of that touches the interface, which keeps drawing throughout, and the progress goes where every other background job's does: one row in the activity register, with a count and a bar. Why the worker does not borrow the session it could have had. A `DevelopSession` owns the `AdjustPass` the canvas renders from, so handing it to a worker would stop the develop view drawing for the length of the batch — the same freeze, moved. Opening a session per image instead costs a `Demosaicer` and an `AdjustPass` each time round, and the pipeline cache is per-pass so the composed shader is recompiled per image rather than once for the run. Against a full-resolution decode, render and encode that is a few percent, and it keeps this file out of the pipeline `develop` owns. A reusable export pass is the obvious next economy if a profile ever says so. The open image is the exception, and it is why the develop button is not simply a one-image batch. Its edit lives in the interface's session and may not have reached a sidecar yet, so a worker that re-opened the file would export the saved version rather than the one on screen. That frame is therefore rendered by the caller and handed over as `Source::Rendered`; everything after the render — the Lanczos reduction, the encode, the write, which is the larger half of the wait and all of its variance — still leaves the UI thread. So the develop export is no longer synchronous, but it is not fully off-thread either, and the doc comment says so rather than claiming otherwise. Cancellation (NFR-ARCH-3) is an `AtomicBool` read between stages, and the export button becomes the cancel button while a run is live — a batch that could only be stopped by not touching the selection would be a trap. Waits on another worker use `recv_timeout` rather than `recv`, so a cancelled batch sitting on a forty-megabyte download gives up within 100 ms instead of when the transfer finishes. The honest bound is worse than that: a frame already in render has no interior stopping point, so the worst case is one image. Closing that needs the render itself to become interruptible, which is NFR-ARCH-2's scheduler and not a finer poll here. Failures are per image and typed (NFR-ARCH-4). One unreadable body, one folder that cannot be written, one server that went away — each is a message on the channel, a line in the log, and a count in the summary, and the batch carries on. A run with any failure keeps its row until it is cleared, because that is the row somebody came to the list to find; a cancelled run does not, because they asked for it. Two collisions that look alike and are not. `CollisionPolicy` is the user's answer to "a file of this name was already there", and Overwrite is a fine answer to that. It is not an answer to "the frame I exported four seconds ago was also called this" — two folders in a library each holding an IMG_0001 is ordinary — so a name the run has already issued is always stepped past whatever the policy says about the folder. Both halves are held by tests. Supporting changes, each smaller than it sounds. `open_session` comes out of `load_bytes` so the worker shares the JPEG-versus-RAW routing rather than carrying a copy that would drift; the half that builds a `slint::Image` stays behind, where it belongs. `LibraryController::selected_image_paths` answers from the catalog rather than from the loaded window, because selection is by id and survives a scrub — a selection made before scrolling routinely names photographs no row holds. `cache_context_for` takes an id for the same reason, so a batch reads the originals cache instead of re-downloading three hundred files. `format_date` is shared so `{date}` and the timeline agree about what day a photograph was taken. Left undone, deliberately: the batch is sequential, where FR-EXP-7 asks for all available cores. Four full-resolution frames in flight is tens of megabytes each and a straightforward way to exhaust a tablet, and the GPU is shared with the interface in any case. Also undone: exporting with a chosen preset rather than the current export settings — that is FR-EXP-5's machinery, which does not exist yet. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-17 09:59:57 +02:00
dtourolleandClaude Opus 5	e00c99b864	Let a photograph leave: an export button, and a cache to leave from ... dr-export could turn a frame into bytes and nothing could ask it to. This is the button, and the place the bytes go. **Everything is staged first.** An export bound for the server is written to a local outbox and uploaded afterwards; offline is not a special case, it is the same path with a drain that finds the server absent. Doing it the other way — upload directly, stage only on failure — makes the failure path the one that is rarely exercised and always broken, and a network drop mid-batch leaves some exports existing and some not with nothing recording which. Staged first, an export is finished the moment it is written and the upload is a promise kept later. The outbox sits beside the catalog rather than under the cache. dr_catalog's cache already draws that line: passive entries are a convenience and go under LRU, pinned ones are a promise and never do. An export awaiting upload is a promise — the user was told it succeeded — and sweeping it for disk would destroy the only copy. Bytes are written before the destination record, so a kill between the two leaves an orphan the drain ignores rather than a record pointing at nothing. The status line says "Queued for Exports/2026", never "Exported to Nextcloud", until it has actually landed. There is a test asserting that wording, because the tempting shorter sentence is a claim the app cannot keep. The drain runs on the sync pass, before the shards: a thumbnail shard can be rebuilt from the originals and the catalog is an index, but a queued export exists nowhere else. `DevelopSession::render_for_export` renders the framed size rather than reusing the frame on screen, which is deliberately viewport-sized (FR-DSP-1) — encoding that would hand the user a soft, screen-sized file with nothing to say anything had been lost (FR-EXP-9). One compromise, recorded rather than hidden: the export runs synchronously on the UI thread, so the window is unresponsive for the few hundred milliseconds a full-resolution render and encode takes. Moving a DevelopSession and its GPU pass to a worker is a larger change than one button earns, and it is batch export that makes the wait intolerable rather than merely noticeable. Still missing: the Nextcloud folder *picker*. The destination is typed into Settings for now. `FolderBrowser` in launch.rs is already the reusable model for it — it browses a remote tree and nothing about it is specific to choosing a library root — but wiring it into the settings page needs a listing worker and browser UI there, which is its own piece of work. Carries in-flight work from a parallel session — presets, the develop copy and paste, and the node schema's `presentation` and `enum` support. One misplaced callback in settings_ui.rs is moved from `render` to `wire`: registered in `render` it borrowed a `&SettingsController` into a 'static closure and would not compile, and that file's own docs say render pushes properties while wire connects callbacks. 992 tests pass, clippy and fmt clean. Traceability 48.3% -> 51.0%. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-16 23:58:17 +02:00