Conflicts with main's --no-maximize-compatibility (#8064) in the CLI
export args, output mapping and dev-dependencies, and in the
file-format parity status line and revision history: both sides kept.
Co-Authored-By: ljkx <ljkx@users.noreply.github.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
#9970 reopened Image > Adjustments > Photo Filter... at the filter, colour,
density and Preserve Luminosity of its last OK. Measured in the reference
application: after OK at 60, 70 and 74 %, with a preset or with Color and a
custom colour, it reopens every time at Warming Filter (85), the orange
swatch and 25 %; only Preserve Luminosity carries over (off after an OK with
it off, on after an OK with it on). Opening now starts from the neutral
settings and takes just that one value from the last OK; Alt still reopens
at all the last settings (#8900). Tests and the ui-parity row follow the
measured behaviour.
Co-Authored-By: ljkx <177671075+ljkx@users.noreply.github.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
CodeRabbit found three things after the last fix-up:
- `engine.execute` and action steps without `name` replied `selected: []`
while the panel listed the layers its kept Name text matches. `run` now
fills in the panel's Name text for every path, as the menu did.
- With Filter Options > Hide, Find Layers left a focus request that took
the caret once the row was shown again. In the reference application the
row stays hidden and showing it later does not focus the field, so the
request is only made for a drawn row.
- The control protocol said the selection never changes; the Name filter
deselects a selected layer it hides (#10879). The doc now says so and
describes each entry point and the reply.
Tests for the first two fail without the fix.
Co-Authored-By: NaufalDzz <NaufalDzz@users.noreply.github.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The decoder set the active area and the crop to the whole plane and never
read ActiveArea, so a file with masked borders and no DefaultCrop developed
with the borders in. Read ActiveArea like the DNG path, use it as the
initial crop, and place DefaultCrop relative to it as DNG does. Also give
3FR/FFF its own row in the camera raw table instead of "embedded preview
only".
Co-Authored-By: Gotya-OFFCIAL <Gotya-OFFCIAL@users.noreply.github.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Resolves the status-line conflicts in docs/gaps.md and
docs/target-app-parity.md (both sides kept) and the module list in
crates/engine/tests/it/main.rs.
Co-Authored-By: arjen <76012639+ArjenS-LA@users.noreply.github.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
main added preferences since the PR's last merge, so the toolColors field now
makes it 10 of 195 settings that do nothing (was 10 of 194 on main); the
ui-parity preference row follows the scorecard.
Co-Authored-By: GyoJoong Kum <david32123kr@gmail.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Create Droplet (CrtD) loads as file.automate.createDroplet for the form
the droplet plays the same way (a Folder destination with Override
Action "Save As"), plays, and saves back as recorded; subfolders, Save
and Close, custom naming, an error log or suppressed dialogs keep the
Photoshop step. The Gradient tool's Make + Set of a gradient fill layer
already map since #10771; a test now covers that recorded form. Print
stays a kept step: its two recorded steps would print twice.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
main moved brush_sections.rs to panels/ with its tests in
panels/brush_sections/tests.rs, and gave the Angle and Roundness fields
accessible names. Keep the PR's left column and right-hand widget with
main's accessible names, move the PR's three layout tests and
section_harness_width into the new tests file, and find the captions with
main's caption_rect (get_by_label now also matches the named fields).
Docs: both sides' status entries kept.
Co-Authored-By: augrclk <217665348+augrclk@users.noreply.github.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
53917dc17 (#9075, Preferences: Skip Transform when Placing, #8492) added
General::skip_transform_when_placing to crates/engine/src/prefs.rs, so the
prefs audit total in the scorecard is 194, not the 193 the committed file
says (the unread count stays 10). The regeneration in 3c4431945 (#11984)
covered #11322's total of 193 but predated this merge, so every open PR's
gate job fails with "docs/scorecard.md is stale: run cargo xtask scorecard
and commit the result".
This is the committed output of `cargo xtask scorecard` at base 67e3457b0:
the Workspace and UI summary row and the prefs-audit prose, 193 -> 194, two
lines, no source changes. `cargo xtask parity` produces no change here.
From the merged tree: the menu count goes to 662 of 662 live, main's 661
plus the Reset Transform item this PR adds, and the prefs audit counts
193 `Preferences` leaves where the committed scorecard still said 192
because main's #11322 added the pref `group_tools` without regenerating.
Both files are `cargo xtask parity` and `cargo xtask scorecard` output,
not hand-edited.
`docs/ui-parity.md`'s status line conflicted: the branch and main each
prepended a clause at the head of the change list, and the branch also
carried the newer `Last updated` date. The merged line keeps main's
toolbar tool-memory clause (#3569) word for word after our Reset
Transform clause (#11662), with one `Change:` header and the later date.
The prefs audit counts 193 settings since Preferences.groupTools landed;
docs/scorecard.md still said 192, which failed the gate and the Windows
staleness test on main.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Review finding on this PR (#11675, discussion_r4499346688): with the warp now cleared as part of
the reset, a smart object whose stack holds a visible filter this build cannot apply took the
Free Transform path's forgiving branch - `refresh_layer` returns false for that stack,
`refresh_text` drops it on the floor, and `restore_unrendered` put the OLD cache back warped by
the relative map. The step recorded a placement at 100 % with no warp whose pixels still showed
the warp.
The step now insists on the guarded refresh the other smart-object edits use:
- `unapplied_filters` is checked before anything changes, so an unsupported Photoshop filter kept
verbatim from a PSD names itself in the error and the document is never touched.
- `refresh_or_fail(doc, id)?` runs at the reset boundary, right after `transform_by_map` and
before the exact map is pinned. It is a cache-warm call in the normal case (same document state
as the render `transform_by_map` just did), and it refuses an unreadable source or a render that
fails outright. Because `Session::edit` runs its closure on a copy and returns early on `Err`,
a refused reset leaves the document, the placement, the warp and the history list exactly as
they were - the fallback pixels are never accepted.
Regression test `reset_transform_refuses_a_stack_it_cannot_re_render` (red before this commit:
the reset returned Ok) asserts the error names the filter, that transform, warp and filter stack
are unchanged, that no history state was added, and that the same object resets normally once the
unsupported filter is off the stack. The four existing reset tests still pass, so the success
path and its warp clearing are unchanged.
No new dependency; photocraft_io's UNSUPPORTED_FILTER was already re-exported by this module.
The ui-parity row, its revision entry and the status line said the Warp survives Reset Transform.
It does not: measured against the reference application 2026-11-06 (report in #11675), the warp is
cleared with the rest of the transform, and the object centres on the average of the placement's
four corners. A 2026-11-07 revision row records the correction; the 2026-11-06 entry stays as the
history of what landed when.
cargo xtask parity and scorecard re-run: unchanged (661 of 661 live), so nothing to regenerate.
David Mann
Hector VillarrealandClaude Opus 5.5
dotCooCoo
Hartmut Nörenberg
FredApps
Sven Carstensen
Davit Matchakhelidze