dtourolleandClaude Opus 5
6a97fdf6f9
Reported from the tablet: the tool rail is very useful there, and the same interface under a mouse and keyboard is not. That is `ui-navigation.md` D-N2's central assumption failing in use, and the interesting part is which half of it failed. D-N2 was right that platform is the wrong axis and width is the wrong axis: a tablet in landscape wants what a desktop wants, and a desktop window dragged narrow wants what a small screen wants. `apply_layout_class` still decides the layout class from the window and nothing here changes that. What D-N2 got wrong is the sentence "touch changes hit regions, not layout" — it identified input as the real difference between the targets and then assumed that difference could never reach the layout. Two controls answer one question — which group of adjustments am I looking at — and neither is better in general. A horizontal strip above the column is one gesture to a target the eye has already found, and it pans when the operation set is rich, so a group can sit off the end with nothing saying so: a pointer user tolerates that, a finger user never discovers it. The same list down the rail is every entry visible at once, each finger-sized, on the edge of the screen the hand is already holding, and it costs no width because the rail is already there. So `ToolRail` grows a second section, and `GroupStrip` stands down when it does. The two are never both on screen, which is why they can share `adjust-tab-picked`: Rust is not told which was pressed and has no reason to want to. Mode and group stay independent axes as N1 requires — one entry lit in each section, and choosing a group while a tool is held still filters without putting the tool down. They stay drawn differently, which N1 also required. The tools fill with `active-dim` and invert their ink; the groups take a bar down the leading edge — the strip's underline turned ninety degrees — so a lit entry says which kind of state it is without the reader having to remember which section it was in. The rule between the sections is the second signal. The rail scrolls now. Its own note argued against a Flickable because "this list is four entries written in this file"; with the groups in it the list comes from the operation set, which is exactly the "something the user's data decides" that note excluded this control from. The axis is input, and it is a preference because the automatic answer is a guess that cannot be made reliable. Neither platform can be asked what the user is holding: an Android tablet in a keyboard case is being driven like a desktop, and a touchscreen laptop is whichever its owner says. `dr_plat::is_touch_first` reports the usual case per platform, and `GroupNavigation` lets it be overridden. Settings names what Automatic resolves to on this device rather than leaving it to be found by pressing. D-N6 records the reversal beside the decision it reverses, including the half that still stands and the question it opens: whether Local is a mode at all, or a scope that would collapse the two sections into one list. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
DarkRoom
A cross-platform, non-destructive RAW photo editor for Linux and Android.
Status: 0.9.0, and no longer a spike. A library opens, culls, develops and exports on both platforms, across eight tagged releases. What is not built is written down rather than merely absent — see docs/outstanding.md for the requirements that have no implementation and why, and docs/technical-debt.md for the compromises that were chosen.
Documentation
| Document | Contents |
|---|---|
| CONTRIBUTING.md | How to land a first change without reading the rest |
| requirements.md | What the software must do — 179 numbered requirements |
| architecture.md | How it is built — crates, GPU pipeline, data model, sync |
| technical-debt.md | Compromises taken deliberately, each with the condition that retires it |
| outstanding.md | What is not built, and whether that is a decision or a gap |
| code-health.md | What a contribution costs, per seam, measured |
| traceability.md | Generated: which requirement is claimed by which file |
| faces.md | Face detection and identity — the models, the licence problem, and what S14 measured |
Building
Desktop:
cargo run -p darkroom-desktop
Android (containerised toolchain, see docker/android):
./docker/android/build.sh cargo ndk -t arm64-v8a build --release
Git LFS is required for the model weights, and the toolchain pins itself. CONTRIBUTING.md has the details and the four commands CI will run against what you send.
Current state
Working. A catalog over a local folder, a Nextcloud account, or a folder a
sync client keeps in virtual-files mode — where a placeholder is treated as the
photograph rather than as a one-byte file. A virtualised library grid with a
capture-time timeline, ratings, labels, keywords, collections and a trash that
survives a crash mid-operation. Card ingest. Face detection and identity, with
the index syncing between devices. A develop pipeline of fifteen declared
operations fused into a single compute dispatch, plus the neighbourhood
operations that cannot be — clarity, texture, capture sharpening, noise
reduction, lens correction, spectral film simulation. Crop, straighten, spot
removal, gradient and subject-segmentation masks, named presets, and a
generated panel that no operation in ui/ is allowed to name. Export to JPEG,
PNG and 8- or 16-bit TIFF with resize and output sharpening.
The zero-copy display path works on desktop. The compute pass writes a texture that Slint composites directly, which is what ARCH §6.1 requires; the readback it forbids costs 96% of frame time at 4K, and
cargo run -p dr-gpu --example bench --features readback
still reproduces that measurement. The one exception is the Android develop view, which reads the frame back through the CPU because zero-copy there needs wgpu's Vulkan swapchain, and that tears a portrait window on a tablet whose panel is mounted landscape. It is debt, not a revision of the rule: the reasoning, the on-device measurements that forced it, and the three separate things any one of which would remove it are in technical-debt.md TD-1.
Not built. Plugins, compare and survey culling, focus peaking, burst grouping, AI denoise, tiled and progressive rendering, and most of the Android platform integration beyond running. The performance targets in §4.1 are unverified rather than unmet — the per-commit benchmark suite §8 requires does not exist, so nothing fails a build on a regression. docs/outstanding.md is the list, with the reasoning.
Licence
GPL-3.0-or-later.