dtourolleandClaude Opus 5 ab4a7e00e7
🐳 Android image / Build and push (push) Successful in 3s
Build and test / android-image (push) Successful in 3s
Build and test / Desktop (Linux) (push) Successful in 19m8s
Build and test / Layer separation (push) Successful in 35s
Traceability / Requirement traces (push) Successful in 29s
Build and test / Android (aarch64) (push) Failing after 9m0s
Leave the adjust panel somewhere to scroll from
A strip down the right-hand edge of the panel that no control reaches, so
there is always somewhere to put a thumb that means "scroll" and nothing
else.

This is the other half of the slider arbitration. A `SliderTrack` stands
the Flickable down the moment a finger touches it, which is what makes
dragging an adjustment reliable — and the price is that the track can no
longer be dragged past. What was left to scroll from was the ~20px band of
label between one control and the next, which on a panel that is mostly
tracks means aiming rather than reaching. Reserving the space outright is
the honest version of what had been left to chance.

Padding rather than a spacer element, and that is what makes it work: the
strip is inside the Flickable but no child is laid out into it, so nothing
puts a TouchArea over it. A press there reaches the Flickable directly,
with no arbitration to lose.

A full touch target wide (FR-UI-3). A gutter too narrow to hit confidently
would be the problem it was added to fix, in a smaller space. It costs the
tracks about 44px of a 280px column, which leaves travel enough that the
readout still moves a step per pixel at the precisions the descriptors ask
for.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-16 15:54:57 +02:00
2026-08-12 22:16:15 +02:00
2026-08-12 22:16:15 +02:00

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.

S
Description
No description provided
Readme GPL-3.0
1 GiB
2026-10-07 11:27:59 +00:00
Languages
Rust 86.1%
Slint 10.3%
Python 1.1%
Shell 1%
WGSL 0.9%
Other 0.6%