The similarity slider stepped and showed whole hundredths, and egui applies both
to a typed value too, so 0.995 became 1.00 before photo.analyze saw it. It now
steps by a thousandth and shows two or three decimals: dragging still lands on
round values, and a typed 0.995 is kept.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The burst-gap and similarity sliders still drag over 1 s-10 min and 0.70-0.99, but
their value fields no longer clamp to that: a typed gap of 0 s to a day ("1800",
"30 min", "1 day") and a similarity of 0 to 1.0 are kept and sent to photo.analyze
as typed; values past the API range are held at its limits.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The Japanese paper-size test exported only the canonical names and then
checked `print.set` with はがき, so the alias-to-MediaBox path was not
covered. Export はがき through `print.exportPdf` as well and read the
same 283.46 × 419.53 pt page as postcard.
Both sides' revision-history rows and change lines are kept (newest first);
print_view.rs auto-merged, so main's shared context_menu call sits beside the
PR's current_paper()/paper_name() punctuation and alias fixes.
# Conflicts:
# ROADMAP.md
# docs/gaps.md
# docs/parity-checklist.md
The paper-name normalisation promised punctuation-insensitive names but
dropped only whitespace, hyphens, underscores and parentheses, so `L判。`
did not resolve; keep letters and digits only instead. The Print dialog
also lower-cased the stored name without resolving it to a canonical
paper, so a paper set through an alias (`はがき`) showed `はがき in` and
selected no option; add `paper_name` and use it for the selector's
current value and option comparison.
Tests: the layout aliases test covers periods and Japanese punctuation,
and the Print view test covers the resolved current paper.
The integration brought #1864: a fresh crop keeps the raw develop
aspect untouched, and the first toggle only records "free" for the
tool (lib.rs interceptor), so reading develop.crop.aspect never
changes on an untouched photo. The lock the row controls is the
effective one - crop_tool_aspect(), which now starts engaged on
"original" - and that is what the test asserts, like main's own
crop_keys. The feature behavior was already right; only the test's
observation point was stale.
1139/1139 ui-egui lib; fmt clean.
crop.lockAspect is declared like any other command (label Lock Aspect Ratio, default A, both keymap profiles) and lists in Help - Keyboard Shortcuts, editable like the rest. The hidden remapping that turned view.visualizeSpots into crop.aspect while the Crop panel was open is gone: the two now share A as a contextual pair - Visualize Spots fires everywhere except under the Crop panel, where the aspect lock takes the key - so A no longer steals the Remove panel from Crop or runs both commands at once (the old remap plus a direct binding would double-toggle). tests_keymap 28/28.
Preserve upstream menu additions and progress documentation while retaining
the focused grid shortcut and native ownership fix. All eight CI gates, five
Windows regressions and native acceptance passed on this exact merged tree.
Co-Authored-By: Codex <noreply@openai.com>
Include effective accelerators in the shared native menu cache key,
with a regression for same-text direct-to-cycle key transfer.
Document the touched menu helpers.
Co-Authored-By: Codex <noreply@openai.com>
Found while testing crates/meta/src/exif.rs:483 (write_exif, the `r` helper; via lightcraft_tiff::writer::rational at crates/tiff/src/writer.rs:261)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
francoisgn