Files
DarkRoom/ui/dr-ui/Cargo.toml
T
dtourolle 5ecb35864f Put the region map behind the sliders that were already there
A mask layer holds a real develop chain, so the develop panel can edit one
with no new controls: select a layer and the same sliders read and write
its chain instead of the graph's. An operation declared in `ops/` tomorrow
becomes locally adjustable by existing, which is the payoff for making a
layer a chain rather than a handful of special-cased parameters.

`segmentation.rs` joins the two arms into the one thing the view needs.
The model reads the image through a neutral graph rather than the edited
one, so a segmentation survives an exposure change instead of being
invalidated by every slider. Arm B failing is not fatal: a missing or
unreadable model leaves a working watershed map, because refusing to
segment at all would trade a working feature for a strict one.

The overlay colours groups by a golden-angle walk over hue. Deterministic
rather than random, so a region keeps its colour across a level change and
the eye can track it; boundaries drawn black over the fill, because two
adjacent groups landing on near hues read as one region and telling them
apart is the whole reason to look at it.

Clicking the photograph creates the layer if none is selected — that is how
a local adjustment begins, and making the user press "add layer" first
would be a step with no decision in it. Shift-click extends, and clicking a
region already selected removes it, so one gesture both adds and corrects.

`segment-readback` is a new dr-gpu feature and not a loosening of
`readback`. The region-graph transfer is once per image on a worker; the
one AC-8 forbids is per frame in the render loop. Sharing a switch would
have forced a build wanting local masking to unlock the other. F3 still
stands and the feature name says so.
2026-08-22 08:39:17 +02:00

105 lines
4.7 KiB
TOML

[package]
name = "dr-ui"
version.workspace = true
edition.workspace = true
rust-version.workspace = true
license.workspace = true
[dependencies]
dr-types.workspace = true
# No `readback`. S1 wired Slint's texture import, so the develop view hands
# the compositor the texture itself and there is no display round-trip left to
# gate (ARCH §6.1, AC-8). The export path reads pixels back through
# `export_pixels`, which is ungated and always was.
#
# `segment-readback` *is* on, and it is not a contradiction of the above. It
# gates the region-graph transfer that local masking is built on: once per
# image, on a worker, off the frame path. The display round-trip AC-8 forbids
# stays behind its own switch, which remains off. See `dr-gpu/src/segment.rs`.
dr-gpu = { workspace = true, features = ["segment-readback"] }
# The semantic arm and its weights, for local adjustments (FR-DEV-3, D14).
dr-segment = { workspace = true, features = ["semantic", "embedded-model"] }
dr-decode.workspace = true
serde_json.workspace = true
tokio.workspace = true
reqwest.workspace = true
dr-plat.workspace = true
dr-sync.workspace = true
dr-sync-nextcloud.workspace = true
dr-export.workspace = true
dr-pipeline.workspace = true
dr-catalog.workspace = true
dr-thumbs.workspace = true
# The library module writes scan results straight into the catalog, so it
# needs the same SQLite types dr-catalog exposes.
rusqlite.workspace = true
# The renderer is shared, but the backend is not: winit on desktop,
# android-activity on Android, and enabling both makes the backend selector
# pick at random. So the backend features live on the target-specific
# dependencies below rather than here.
#
# `renderer-femtovg-wgpu` rather than `renderer-femtovg`: the latter is
# FemtoVG over OpenGL, and a compositor drawing through GL cannot be handed a
# `wgpu::Texture`. Importing one requires Slint itself to be rendering with
# wgpu, and this is the FemtoVG backend that does (ARCH §6.1, spike S1).
#
# `unstable-wgpu-29` is the other half: the renderer feature makes Slint draw
# with wgpu, and this one exposes the API to say so — `BackendSelector::
# require_wgpu_29` and `Image::try_from(wgpu::Texture)`. Unstable is Slint's
# word for it; the surface is small and the alternative is the 7 ms round-trip.
#
# `renderer-femtovg` is *not* kept alongside as a fallback, though it would
# still compile. Slint's winit backend prefers the wgpu FemtoVG renderer
# whenever both are built, so the GL one would only ever be reached by someone
# setting `SLINT_BACKEND=winit-femtovg` — and on that path an imported texture
# is not drawn at all. FemtoVG-over-GL has no branch for a `wgpu::Texture`, so
# it falls through to "render this image to a buffer", gets nothing back, and
# draws nothing. A blank canvas with no error is a far worse failure than the
# one below, so the fallback is removed rather than left as a trap.
#
# Consequence worth stating plainly: the desktop app now needs a working wgpu
# adapter to open a window at all. Slint refuses a CPU adapter for this
# renderer unless `SLINT_WGPU_CPU` is set in the environment.
slint = { workspace = true, features = [
"compat-1-2",
"renderer-femtovg-wgpu",
"unstable-wgpu-29",
] }
wgpu.workspace = true
anyhow.workspace = true
# `SettingsError` distinguishes an io failure from a malformed file, which the
# settings page reports differently; anyhow would flatten both to a string.
thiserror.workspace = true
log.workspace = true
pollster.workspace = true
# Runtime YAML only for `live-style`; release builds read the tokens the
# Slint compiler folded in at build time and never touch style.yaml.
serde_norway = { workspace = true, optional = true }
# Backend per platform. Slint already declares its android-activity backend
# under `cfg(target_os = "android")`, so this only has to name the feature;
# cargo resolves it away entirely on desktop.
[target.'cfg(not(target_os = "android"))'.dependencies]
slint = { workspace = true, features = ["backend-winit"] }
[target.'cfg(target_os = "android")'.dependencies]
slint = { workspace = true, features = ["backend-android-activity-06"] }
# Opening the sign-in URL needs an ACTION_VIEW Intent — Android has no
# xdg-open. Version-matched to Slint's Android backend so both halves of the
# process agree on the JavaVM types; ndk-context supplies the VM and activity
# that android-activity's glue already stashed.
jni = "0.22"
ndk-context = "0.1"
[build-dependencies]
slint-build.workspace = true
# build.rs generates theme.slint from style.yaml (S2).
serde_norway.workspace = true
[features]
default = []
# Debug convenience: re-read style.yaml at startup so a palette can be tuned
# without rebuilding. Costs the constant-folding of every token, so it stays
# off by default and has no business in a release build.
live-style = ["dep:serde_norway"]