Main split the panels' value editors into one function per value kind.
The expression colour now comes from Tokens::for_value in each of them:
Effect Controls through PropCx::value_tokens, the Timeline's scalar,
vector and enum editors, and the Properties transform row.
Groups, paths, fills, strokes and operators in a shape layer's Contents show the
Video eye in the A/V column (a group's Transform doesn't). Clicking it runs
prop.setGroupEnabled, which the shape renderer already honours; layer-style
eyes keep layer.style.toggle. Row building and search results share eye_of.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
CodeRabbit's leftover nitpick: h264_mp4 hard-coded -preset medium -crf 18 for
whatever encoder the build ships, but libopenh264 (and the hardware backends)
reject both — so a build whose picked encoder is not libx264 failed the fixture
and silently skipped every check gated on it. libx264 keeps its constant-quality
pair; everything else gets -b:v. Pinned by a small test over the option sets.
- Exported HEVC/AV1 nclx says BT.709 and limited range where the pipeline
means it, matching what the players we tested assume; the round-trip
tests pin the box values.
- The ffmpeg oracle helpers no longer read the flags column of
`ffmpeg -decoders` for "is a decoder" — every row of that listing is a
decoder, and the trailing D there is "supports direct rendering method
1", which a build's hevc decoder may legitimately lack. Decoders are
matched by the codec-name column alone.
- Fixtures a given ffmpeg build cannot actually encode (a listed encoder
that fails at run time: hardware backends without their device, the
noopenh264 stub) skip with a note instead of failing the run.
CodeRabbit and FredApps both flagged that the preflight probed only the plain
PKG_CONFIG variable, while the pkg-config crate alsa-sys pins resolves the
target-scoped variants first and falls back pkg-config -> pkgconf; on a host
with only pkgconf the ci stage failed a build that would succeed. The probe
now goes through the same crate (0.3.34, already pinned via alsa-sys), so the
semantics match by construction, and a probe that ran but said no stays
distinct from one that could not run.
Also from review: audio_backend_hint is gated to Linux (bflatastic: dead code
on Windows/macOS under -D warnings), the fake-tool regression runs the real
xtask audio-backend task in a child process with a controlled environment
(pkgconf-only host, a probe that says no, one that cannot run, a HOST_PKG_CONFIG
override), the rerun-if-env lines stay out of the ci log, and CONTRIBUTING.md
asks for a usable alsa.pc and runtime library rather than development headers.
The probe's spawn failure (a PKG_CONFIG that names nothing runnable, or
pkg-config absent from PATH) reported the ALSA-missing hint, sending
the reader off to install alsa-lib they may well have: a failed launch
now reports itself, naming the executable and pointing at
installing pkg-config or correcting PKG_CONFIG, while a probe that
runs and exits non-zero still gets the ALSA guidance.
The probe ran pkg-config straight from PATH while the build's alsa-sys
goes through the pkg-config crate, which reads PKG_CONFIG first: the
variable may name a working pkg-config that is not on PATH, and then
cargo xtask ci would report ALSA as missing over a build that finds
it. The probe now selects the same executable the same way; no test
stands over it because the probe needs a real pkg-config environment
(the hint is split out for exactly that machine-dependence).
When the ALSA development package is missing, `cargo xtask ci`'s audio
stage failed at link time with a bare linker error. The check now says
which package installs ALSA's contents on each supported distro, the
missing one is named in the error, and the stage's own tests pin both
the present-ALSA pass and the per-distro message.
BFlat
tylerjenningsw
midasdf
Kaedo17
Jerome CAMUSandClaude Sonnet 5.5