crates/ui-egui/src/panels/left/folders.rs: main's built-in-place guard around Rename and Move kept; the Move item is the PR's move_folder_item inside it.
docs/parity-checklist.md: the PR's edits to its rows applied to main's rows.
docs/whats-new.md: the PR's entry added under the 2026-10-29 heading.
docs/parity-checklist.md: the PR's edit to the LRC-LIB-CATALOG-SWITCH row applied to main's row.
docs/whats-new.md: the PR's 2026-10-29 section added above main's sections.
docs/parity-checklist.md: header keeps main's newer date plus the PR's item; the PR's edit to the LRC-LIB-FOLDERS row applied to main's row; revision rows union, newest first.
docs/whats-new.md: the PR's 2026-10-28 section added above 2026-10-27.
crates/engine/src/import/job.rs: union of the imports (main's Seen, reusable_probes, sidecars_of plus the PR's FileFacts); the sidecar read uses main's batched found_sidecar and the PR's skip for duplicates with a known capture time.
crates/engine/src/import.rs, cmd/library.rs: main split these files; kept main's side here and ported the PR's hunks to import/job.rs, cmd/library/import.rs and cmd/library/specs.rs (module doc stays in import.rs).
docs: headers keep main's newer date plus the PR's item; the PR's row additions applied to main's rows; revision rows and What's New entries kept, one heading per date.
docs/parity-checklist.md: header keeps main's date plus the PR's item; the LR-IMP-ADD-DIALOG row keeps main's text and gets the PR's sentence; revision rows union.
docs/whats-new.md: both entries kept.
docs/gaps.md, docs/parity-checklist.md: header keeps the newer date plus both sides' items; revision row added newest first.
locales/ru.json: union of keys.
docs/gaps.md, docs/parity-checklist.md: kept main's header and rows, added the PR's video text and revision row.
crates/engine/src/lightroom_catalog.rs: the PR's two tests moved to lightroom_catalog/tests.rs (main split the module).
Dropped the PR's unrelated hunks (slide_overlay.rs, tests_export.rs, raw corpus tests) per the review.
A data line such as `nan 0 0` starts with a letter and was skipped as an
unknown keyword, so a file with enough other entries still parsed.
(CodeRabbit review on #2540.)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Some Samsung panoramas have no end-of-image marker: the scan data runs
straight into the SEF trailer at the end of the file, so the header
check refused them as truncated, and jpeg-decoder (DCT-scaled previews)
and zune-jpeg both fail on the trailer's bytes after the scan.
When the file ends with a valid SEF trailer (SEFT, a directory length
that points at SEFH, a sane entry count, every entry's block inside the
file before SEFH) and no EOI is reached, the image is read as the bytes
before the earliest SEF block plus an EOI, for both the header and the
decode. The cut must fall in scan data after the first SOS; a JPEG cut
short without such a trailer is still refused.
Since a content duplicate carries its file's capture time, the duplicate
check ran after the sidecar read, so a duplicate whose file already has
a capture time read and parsed a sidecar it doesn't use (more I/O on a
network share). The check now happens first and the sidecar is read for
a duplicate only when the file has no capture time.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
UPDATE_APP (native builds; craft-update is a native-only dependency) carries our 128 px icon and accent (#f2a516, its colour in ArtCraft Launcher). The updater, the self-update
helper and craft-update's startup prompt all get them through crate::UPDATE_APP; the
prompt draws the icon, the accent and "by ArtCraft" (craft-update's default developer).
craft-update is pinned to storytold/craft-libs main at 1065653e7 (#434).
Clippy fixes for Rust 1.99 in untouched code (same logic):
- crates/engine/src/cmd/export.rs
- crates/ui-egui/src/dialogs/rules_editor/rules_move.rs
- crates/ui-egui/src/panels/detail.rs
A content duplicate whose catalog row has no capture time took the
capture time of the library photo with the same bytes, which Edit
Capture Time may have changed. The import job now resolves the file's
capture time (the file's, else its XMP sidecar's, else its modification
time) before it sets the file aside as a duplicate, and hands it over
with the file's metadata (`Duplicate::file`, a `FileFacts`). The
Lightroom import uses it; the catalog's capture time still applies on
top when the row has one.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A catalog photo whose bytes match another library photo became a new record that took only the
camera description from that photo's record, so the copyright, rights, creator and other metadata
its file carries (EXIF, IPTC, embedded XMP), which a file import keeps, was lost whenever the
catalog's XMP didn't restate it. Copying them from the other record would have carried that
photo's edits instead.
The file import already reads each content duplicate before it skips it; the probed metadata now
rides on the duplicate (`Duplicate::file_meta`, not serialised) and the new record starts from it,
before the import defaults and the catalog's metadata go on top, as for a file import. Without a
probe (a path match, which this branch never sees) it keeps the exposure description only, no
longer the user-editable GPS.
Test: a content duplicate of a trashed photo, imported through the Lightroom job with a file
carrying copyright, status, usage terms and creator, keeps them and takes nothing from the other
record's edited notice, creator or GPS.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A catalog photo whose bytes match another library photo got the generic develop defaults, so a raw
with no white balance or lens setting in the catalog lost its as-shot white balance and embedded
lens corrections and rendered unlike a file import. It now gets the import defaults (camera
defaults plus the default preset), as a file import does, before the catalog's settings go on top.
Show in Library selected the lowest mapped photo id, which can be a master left in Recently Deleted
whose new virtual copy the import added; All Photos doesn't show it. It now selects the lowest
mapped photo not in Recently Deleted, and the button is left out when there is none.
Tests: a content-duplicate raw with no catalog settings equals its camera defaults (as-shot WB,
lens profile on); Show in Library skips a trashed mapped photo and offers nothing when only
trashed or vanished ids are mapped.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The new record for a catalog photo whose bytes match another library photo copied that whole
record and reset a few fields, so the other photo's edits, history, versions, ratings and written
metadata (title, keywords, face regions) carried over, from a trashed photo too. It now starts as a
new photo and takes only what the bytes determine: format, size, kind, capture time, camera EXIF,
GPS, focus point, content hash, embedded lens data and preview-only state. The catalog's own
settings and metadata apply on top as before.
Tests: the duplicate test gives the other photo edits, history, a version, a title, keywords and a
Local baseline and checks none reach the new record; a reimport after a master and its virtual copy
were trashed counts each once.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A catalog photo whose file matched a photo in Recently Deleted by content was cloned with the trashed
record's `deleted` flag (and its virtual-copy fields), so it landed in Recently Deleted while the report
counted it as imported. A new virtual copy of a trashed master did the same. Both are now live records,
as Create Virtual Copy already does.
Catalog photos matched by path to a trashed photo stay there (the Lightroom import's OnDeleted::Skip,
#706); the report counts them as `inRecentlyDeleted` and the result window says so in one line.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
AGENTS.md (and CLAUDE.md where present) gets a CI workflows section: workflows only call
craft-common-actions at @main, with no other jobs; feature and fix PRs don't touch CI and
link or open a craft-common-actions issue (a PR only for a small fix that is safe for
every app and does not increase CI time); legacy jobs
aren't added to and move only as their own task, staying until a shared workflow runs them.
windows-arm64.yml moves from its SHA pin to @main. The pinned revision is on
craft-common-actions main and the workflow (and the actions it calls) is identical
there, so nothing changes in behaviour.
aiongg