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>
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.
Remove the Azerbaijani menu coverage test (red on main), the crop Fill
label coverage test and the has() loop in the pen path Esc test. A
missing string falls back to English; cargo xtask i18n-coverage lists
the gaps. docs/contributing.md now says tests never require a string to
be translated.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
cargo xtask parity and scorecard on the merged tree: 661 of 661 menu items live (Layer 162 of 162, so the Reset Transform row is counted live), and the prefs audit is 10 of 191 now that upstream removed the Enable animations preference.
Unset or null follows Preferences › File Handling: Always and Ask When Saving
write the real merged image, Never the placeholder, and app.save opens no dialog.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The PSD writer always writes the real merged image for those modes (Bitmap and
Indexed are saved without layers; Duotone is exempt), so maximizeCompatibility
false does not give them the placeholder. The MCP params, control protocol and
CLI help now say so.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Photoshop's Maximize Compatibility checkbox, for one save: `maximizeCompatibility`
(true or false) on Save, Save As, Save a Copy, `app.save`, serve `doc.save`, MCP
`doc_save`/`doc_export`, Batch, Image Processor and Layers to Files decides the
merged image over Preferences > File Handling > Maximize PSD and PSB File
Compatibility; unset, the preference decides. Anything but a boolean is refused
before anything is written. The CLI takes `--no-maximize-compatibility`.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
David Mann
David Mann
Hector VillarrealandClaude Opus 5.5
dotCooCoo
Hartmut Nörenberg
FredApps
Sven Carstensen
Davit Matchakhelidze
Cristi RaduandClaude Opus 5.5