Resolves the parity summary (regenerated), drops a duplicated #[cfg(test)], files the What's New entry
under today's date and bumps the checklist's Last updated line.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Conflicts:
- apps/lightcraft/src/native_menu.rs: upstream's item swapping (macOS keys
given up for real, Help menu not swapped, Settings / Quit tracked) with
KEY-GRID's keymap-aware rows. `Item.label` stays the text the row shows
(native_item_presentation), so `Item::native_label` reuses it instead of
formatting it again; Settings / Quit store theirs through
display_item_label, as upstream's native_label did. No early return after
a rebuild (upstream).
- crates/ui-egui/src/i18n.rs: upstream's tests (#2729: one test per check
across languages, gaps reported, never a failure) plus the batch's two new
ones (dropped-photos notice, Polish counts); production code as merged.
- grid.rs, keyword_list.rs, masking.rs: the translation tests #2729 removed
stay removed; the batch's new keyword and segmenter tests stay.
- cmd/library.rs, ui-egui/src/lib.rs: both test modules, each with its
#[cfg(test)].
- xtask/src/main.rs: #2302's test_selected and upstream's translation_gaps.
- docs: tracker / gap rows take both sides' edits, headers list both sides'
changes, history rows of both sides newest-first. What's New: one section
per date, newest first (the batch had 10-22 above 10-23, and second 10-21
and 10-19 sections); no line lost.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Lightroom Classic's histogram is a control surface: its plot is split into five
tonal zones and each one moves the Basic control it names. The Edit panel's
histogram now does the same, wired through the engine like every slider.
- Zones: Blacks 0.00-0.15, Shadows 0.15-0.35, Exposure 0.35-0.65, Highlights
0.65-0.85 and Whites 0.85-1.00 of the plot's width, each naming the develop
control it adjusts (light.blacks ... light.whites), so its range, default and
steps are the panel's own control specs -- no copy of them.
- The zone the press landed in stays locked for the whole drag (the new
Gesture::HistogramDrag), so the pointer may cross the others without switching
control. The strip under the plot (the readout and the EXIF line) and the
clipping buttons in the plot's top corners are not zones.
- A sideways drag dispatches develop.set between develop.beginInteraction and
develop.endInteraction -- the sliders' own path -- so the draft render follows
the drag live, nothing is committed while it goes on, and the release lands the
whole drag as one undo step. Travel of the plot's width sweeps the control's
whole range (Shift a tenth, as the sliders' fine drag) and clamps to its spec;
the unrounded value is carried from frame to frame so a slow drag adds up
rather than rounding back to the step it already has, and the first reported
frame takes the whole travel from the press, since egui withholds a drag until
the pointer has left its click threshold.
- Hovering a zone tints it and names it with its value in the strip under the
plot ("Exposure: +0.45 EV"), replacing the EXIF line, and the pointer shows the
sideways-resize cursor. A double-click in a zone puts that control back to its
default in one undo step.
Tests: the zone mapping at every boundary, the tiling and the controls' specs,
the drag/rounding/clamping arithmetic (hostile input included) and the readout
wording; end to end through the control channel: a drag per zone, the zone lock
across the plot, the Shift ratio, clamping at both ends, live dispatch with one
undo step on the release, the double-click reset, the hover highlight, readout
and cursor, and a drag on the readout strip or clipping chevrons changing nothing.
Docs: the tracker's LRC-DEV-HISTOGRAM-DRAG row added and LR-VIEW-HISTOGRAM's
"no drag-to-adjust" note replaced, with the summary regenerated by
`cargo xtask parity --write`; a dated entry in docs/whats-new.md.
Sources: own design; the zone layout and Lightroom Classic's histogram-region
behaviour as the reference (observed read-only).
Co-Authored-By: deepseek-flash <noreply@deepseek.com>
dialog_field took the focus back every frame while the field wasn't being edited, so Tab never
reached the check box, Cancel or OK of New Album, New Smart Album, Save Metadata Preset and the
other one-field dialogs. It now takes the focus once, when the dialog opens (the way the keyword
dialogs already did).
crates/ui-egui/src/lib.rs: the batch's handle_dropped_files refuses presets
while no library is open, as #2701 does. The drop card says so, and its
"photos wait" line is desktop-only (the web build's drops import into its
session as before). photos_dropped_with_no_library_open_wait_for_one also
drops a preset; LR-IMP-DRAGDROP row updated.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Presets belong to a library (presets.json, <library>/Profiles): dropped
while the launch list or the failed-library window is up, they went into
the session the library opened then replaced. They are refused with a
toast now; the photos of the same drop still wait for the library. Docs:
What's New, control protocol, the #1290 tracker row.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Review round: whether a recent library is there is kept apart from whether it can be
opened. `Unavailable::is_missing` (not found, a file, no library, a folder that can't be
listed) is the only answer that greys out File ▸ Open Recent Library and makes
`app.recentLibraries` say `exists: false`; an unreadable catalog or a failed check gives
`null`. A failed open from the launch window (say another program has the library)
drops the answer so it is checked again, instead of storing the open's error as one; the
launch list keeps the error on its row. Test: Open on a locked library from the launch
window, then the menu entry stays enabled and `exists` is true (fails if a failed open
marks it missing); an unreadable catalog gives `exists: null`. Docs worded to match.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Review round (CodeRabbit + an adversarial review, handled together):
- The launch list starts with every row "Checking…" and a worker per path checks it (a
share whose server is gone, or a sleeping disk, can take seconds or never answer; one
that hangs doesn't hold the others). After 5 s a row says the drive isn't answering;
it can still be opened. Once every answer is in, the selection moves to the first
library that can be opened, unless the person moved it.
- File ▸ Open Recent Library and `app.recentLibraries` no longer look at folders either
(the menu is rebuilt every frame): they use the same answers, refreshed after 30 s, when
a library is opened, removed from the list, or fails to open. `app.recentLibraries`
gives `exists: null` and `checking` until a check answered.
- Reasons are found on the worker and put into words on the UI thread, in the interface
language. A check whose worker dies ends as "This library couldn't be checked".
- Each check holds an activity row ("Checking recent libraries"; quick ones don't show).
- Docs: control protocol (`checking`, `available`, `exists`), What's New; fr strings.
Tests: slow check never holds the window; late answers keep the person's selection; the
menu takes its answers from a worker (fails with the old is_dir()); reasons in French; one
hung drive doesn't hold the others; a dying check ends; reopening clears a missing answer.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The launch window no longer probes each recent library with the lock check
of File > Open Library (which created catalog.lock and wrote
catalog.lock.owner into every free library at every launch, including
other drives, network shares and sleeping disks). A row is now checked by
looking only: the path exists, is a folder, can be listed, holds a
LightCraft catalog, and that catalog opens for reading. A library another
program has open is found when Open is pressed: the open fails with the
lock owner's message, the window stays and greys the row out.
New test: listing (and drawing the window) leaves every library folder
byte-identical (contents and modification times); it fails with the old
probe. Docs (What's New, parity row, control protocol) say so.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AbegtYaPuwqZ81pGfELsFK
Settings > General > At launch: Open the last library (default, as before)
or Ask me. With Ask me the desktop app opens nothing and the library-problem
window lists the recent libraries instead (name, folder, when last opened;
missing, locked or no-longer-library ones greyed out with the reason; the
last one selected): Open, Open Another..., New Library..., Remove from List,
Quit, with arrows / Return / Esc. Alt/Option held in the first 2 s after the
window appears shows the same list once over the library that opened (winit
reports no modifiers before the first frame; macOS only on a change).
File > Open Recent Library > Remove from List and
app.recentLibraries {remove: path} forget one entry; nothing on disk is
touched. The list reports lastOpened, kept under a new settings key
(recentLibrariesOpened) so older files and versions keep their list.
--library and LIGHTCRAFT_LIBRARY keep priority (launch_plan), --memory never
asks, lightcraft-cli never reads ui.json. Settings are saved while the list
shows; command-line files go into whichever library opens.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AbegtYaPuwqZ81pGfELsFK
LRC-LIB-CATALOG-IMPORT. Before File ▸ Import Lightroom Catalog… starts, a
window asks where the catalog goes: merge into the open library (named,
with its photo count; preselected when it is empty) or create a new
library named after the catalog file, next to the open library (both
editable, Choose… picks the folder). The new library is made and opened
through app.newLibrary (its rules: an empty or new folder, refused while
another import runs), then the catalog is imported into it. Cancel does
nothing. Open Library… on a Lightroom catalog goes through the same choice.
Opt-out: Settings ▸ General ▸ When importing a Lightroom catalog (Ask
where to import it / Always merge into the open library), saved as
ui.json settings.lightroomImport (lenient, default ask); the window's
"Don't ask again" picks Always merge. A session in memory merges without
asking, as before.
file.importLightroom takes {into?: open|new, name?, location?} to choose
without the window. UI layer only: library.importLightroom, the engine
and lightroom_import.rs are unchanged.
Tests: decision table (setting x library on disk/in memory x photos x
into), params, default name; headless window / merge / new library /
cancel / empty library / setting / Don't ask again persisted / folder
not empty / into / in memory / stale library; tests_open_lightroom
follows the new window. Format messages in all 17 catalogs, plain
strings in French. Docs: lightroom-catalog-import, control-protocol,
parity-checklist, whats-new.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AbegtYaPuwqZ81pGfELsFK
Measured on 68 photos straightened by hand in Lightroom Classic and 300 left as shot, Auto
straighten turned 79 of the 300 by more than 1° (65 by more than 2°): the edges of planks, a
branch or a bird's wing were taken for the horizon. It now answers only for at most 10° and on at
least 3 agreeing lines (Upright Level is unchanged): 19 of the 300, with the same 14 of the 68
levelled within 0.5° and 1 instead of 3 more than 1° off. When it finds nothing, the app says so
instead of leaving the photo without a word. LR-CROP-AUTO goes to 🟡: it still leaves most tilted
photos alone.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Find Missing Photos took a missing photo's file name with Path::file_name,
which doesn't split on `\` on macOS or Linux, so a library made on Windows
had photos it could only find by content: those with no hash on record
(Lightroom-catalog imports, files edited since) were never found. Both the
missing photos and the files found on disk are now named by one rule: the
part after the last `/` or `\`, in lower case.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
LibraryLock::acquire wrote catalog.lock.owner with std::fs::write,
which follows a symlink at that name. A library folder someone else
prepared (a shared drive, an unpacked archive, a synced folder) could
carry catalog.lock.owner -> ~/.bashrc or any other file the user can
write, and opening the library replaced that file's content with the
owner JSON. The catalog's staging files had the same problem and were
fixed in #1502; the owner note was missed.
The note is now written through store::create_staging (made
pub(crate)): whatever is at the name is removed (a link itself, never
its target) and the file is created with create_new. Drop already
removed the note with remove_file, which never follows a link.
Test (Unix): a link at catalog.lock.owner pointing at a file outside
the library leaves that file's bytes unchanged through acquire and
drop, and the note lands in the library as a regular file naming this
process.
Reported-by: BS.ehlas.cz
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>
With `Places|Italy|Rome` on the selected photos, the boxes of `Places`
and `Italy` were empty: a folded keyword gave no sign that something in
it was applied.
A keyword whose own box is empty now carries a dot in it when the
selection has a keyword inside it, at any depth, and the box's tooltip
names what is inside ("Inside: Rome, Venice", four by name, then a
count). The tick and the dash stay about the keyword itself and come
first: a keyword the photos have themselves shows that, not the dot. A
click on the box does what it did.
What is inside each keyword is worked out with the ticks, once per
selection (`Ticks::inside`), not per row and frame.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The parity row and the What's New heading said one star rating 'everywhere', but the
Set Rating / Select By Rating menu rows and the grid context menu are separate menu
items with star text and are unchanged. Name the real scope.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The bottom bar, the Info panel and the filter bar each drew their own
row of stars, and the grid badge, filmstrip badges and compare caption
had private painter loops. They now share rating::Rating (a clickable
row: hover previews, clicking the current rating clears it, read-only
and disabled states, left/right arrows on a focused star) and
rating::paint_rating / paint_star for painter-only contexts.
Existing automation ids (star:bottom:n, star:info:n, filter:starN) are
unchanged. The preset, profile and theme favourite stars use
paint_star too, so Icon::Star lives only in rating.rs.
Co-Authored-By: Claude <noreply@anthropic.com>
Brandon Thomas