dtourolleandClaude Opus 5 ff6c313bab Wrap the chip rows, so one six-choice parameter stops sizing the sidebar
The develop column asked for 482px. Every comment in it, a dozen of them,
describes it as a 280px column — and on a tablet it was taking 40% of the
screen from the photograph it exists to serve.

Measured rather than guessed, because none of it is visible in the source:
the column takes the widest width any panel declares, `AdjustPanel` wanted
482 of it, its rows wanted 458, and after the 44px scroll gutter the
widest single row was 414. That row is `film_sim`'s `format` — six film
formats from 35mm to 8x10, laid out by `Segmented` as six 64px chips in a
`HorizontalLayout` that cannot wrap. 6 x 64 + 5 x 6 = 414, exactly.

Nothing about that is the film simulation's fault. An operation declares
its parameters and the panel decides how to draw them (FR-DEV-3a), so a
node is entitled to offer six choices; it is the drawing that has to cope.
Any future operation with a five-choice enum would have done the same
thing, silently, to every screen in the application.

`ChipGrid` is the general answer: chips placed by index arithmetic inside
a plain `Rectangle`, wrapping at a column count, declaring a width that
depends on the columns rather than on the number of choices. `Segmented`
takes a `columns` property and uses it when asked — zero, one row however
many chips, stays the settings page's behaviour, where the page is
full-width and reading the alternatives side by side is the whole argument
for chips over a dropdown.

The generated enum rows and the curve-channel picker now wrap at three,
and the crop ratio chips use the shared grid instead of the private copy
of it they shipped with last week.

The column measures 351 now, down from 482, and what sets it is the mode
strip rather than a parameter — which is a control the user chose to have
on screen rather than an accident of one node's variant list.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-29 19:16:43 +02:00
2026-08-29 13:53:19 +02:00
2026-08-26 10:08:51 +02:00
2026-08-29 13:53:19 +02:00
2026-08-29 13:53:19 +02:00
2026-08-27 19:33:37 +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
faces.md Face detection and identity — the models, the licence problem, and what S14 measures

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%