dtourolle
85dafd78b7
Local adjustments took the develop column from four panels to six, and the operation set is meant to keep growing — FR-DEV-3 still lists texture, clarity, sharpening and noise reduction as v1. But the count is the lesser problem. The real one is that local adjustments introduced a *mode* without introducing a way to see it. Selecting a mask silently re-points thirty sliders at that layer, and the histogram those sliders are judged against goes on reporting the whole frame. I built that, and it is the fault that loses work rather than merely slowing someone down. Decided: local becomes a mode, in the sense `crop-mode` already is. The app has the pattern, the user knows it, and it removes the ambiguity by construction instead of describing it in a caption. It also inherits the Escape/back stack that already leaves the innermost state first. Recommended: diverge on **width**, not on platform. A tablet in landscape wants what a desktop wants and a narrow desktop window wants what a phone wants, so `cfg(target_os)` would give one physical situation two answers. `apply_layout_class` already classifies on width and already remembers a per-class override; this is a second consumer of a decision the app makes anyway. What must not diverge is the controls — both layouts consume the same generated capability model, so a new operation still needs no UI edit. Left open, because it is taste: whether the wide layout eventually gains tool tabs. Recorded rather than left to be rediscovered is the *legitimate* route to them — a descriptor declaring an operation's nature, the same shape as `Affects`, with the frontend free to render it as a tab or ignore it. Deferred because ten operations do not need eight tabs and the field is easy to add later and awkward to remove. Surveys what Lightroom, Capture One, darktable and the phone editors actually do, including the thing none of them do: make a mask a panel that rewires a different panel.
DarkRoom
A cross-platform, non-destructive RAW photo editor for Linux and Android.
Status: early. v0.1 is a remote library viewer — see docs/milestone-v0.1.md.
Documentation
| Document | Contents |
|---|---|
| requirements.md | What the software must do — 122 numbered requirements |
| architecture.md | How it is built — crates, GPU pipeline, data model, sync |
| milestone-v0.1.md | The first buildable milestone |
Building
Desktop:
cargo run -p darkroom-desktop
Android (containerised toolchain, see docker/android):
./docker/android/build.sh cargo ndk -t arm64-v8a build --release
Current state
Working: workspace, GPU context and compute pass, adaptive Slint shell, Android cross-compilation of the core crates.
Not yet working: the zero-copy display path. The build currently uploads frames through the CPU, which is exactly what ARCH §6.1 forbids — measured at 96% of frame time at 4K. Replacing it is spike S1, the project's highest priority.
cargo run -p dr-gpu --example bench --features readback
reproduces that measurement.
Licence
GPL-3.0-or-later.