crates/ui-egui/src/tests_grid.rs: both sides' tests
docs/whats-new.md: both entries under one 2026-10-16 heading
docs/parity-checklist.md: header and revision rows from both sides
crates/ui-egui/src/panels/grid.rs: badge keeps main's double-click guard and calls #2300's toggle_stack
crates/ui-egui/src/tests_grid.rs: both sides' badge tests
docs/parity-checklist.md: header and revision rows from both sides; rows take both changes
crates/ui-egui/src/panels/detail.rs: #2317's split (info_overlay / info_overlay_lines / info_overlay_extent) kept; info_overlay_lines builds its lines from #1965's View Options fields (info_line) and returns None when off or when no line is left
crates/ui-egui/src/panels/dialogs.rs: only_shows keeps Dialog::ViewOptions and the up-to-date Synchronize Folder case
crates/ui-egui/locales/it.json: union of keys
crates/ui-egui/src/tests_zoom.rs: both new Before-label tests, with #1968's comment wording on the crop test
docs/whats-new.md: both entries under 2026-10-19
* Use chrono for UTC/calendar conversion instead of hand-rolled copies
Replaces the hand-rolled Howard Hinnant civil/days-from-civil copies and the
leap-year/days-in-month table with chrono as a workspace dependency:
- apps/lightcraft/src/logging.rs: timestamp (log line time)
- crates/catalog/src/dates.rs: civil + weekday
- crates/catalog/src/stacks.rs: iso_seconds (date -> seconds)
- crates/engine/src/cmd/face_recognize.rs: capture_secs (native only)
- crates/meta/src/datetime.rs: DateTime::unix_seconds and the valid() day check
Output formats and semantics are unchanged (pre-epoch clamp, day rollover that
normalize_iso relies on, leap-second tolerance, EXIF/XMP parsing). chrono uses
only std, so wasm stays safe. AGENTS.md/CLAUDE.md now say time goes through chrono.
Follow-up to storytold/cadcraft#1785
* Never panic on a clock outside chrono's range; keep 5-digit years unprefixed
chrono's From<SystemTime> unwraps, so a clock past year 262143 panicked
inside the logger. timestamp now uses the fallible DateTime::from_timestamp
and reads such a clock as the epoch, keeping the old pre-epoch clamp.
timestamp and catalog's civil write years past 9999 with {:04} like the old
{y:04} did, because %Y would add a '+'. Tests cover the out-of-range and
5-digit-year cases.
* Don't build an unrepresentable SystemTime in the far-future test
UNIX_EPOCH + Duration::from_secs(u64::MAX / 2) overflows Windows'
SystemTime and panicked before timestamp() ran, failing the Windows
test job. Build it with checked_add and only assert where it exists.
* time: preserve old out-of-range date conversion (no epoch fallback)
`DateTime::from_timestamp(...).unwrap_or_default()` silently reset any instant
past chrono's year range to 1970-01-01, changing output the old hand-rolled
Howard-Hinnant code converted exactly (e.g. 10_000_000_000_000 s was
318857-05-20 17:46:40, not the epoch). Restore the old conversion domain with a
cycle-based helper that routes the calendar through chrono (the calendar
repeats every 400 years = 146_097 days, so month/day/time come from chrono and
only the year is carried in i128, keeping every i64 exact).
- apps/lightcraft/src/logging.rs: `timestamp` via `utc_parts`; keep the
pre-1970 epoch clamp; u64 secs past i64::MAX saturate, not epoch.
- crates/catalog/src/dates.rs: `civil` cycle-based (the callers stay inside
0000-9999, but a far clock no longer resets to the epoch).
Pinned old outputs in tests:
logging u64::MAX/2 s -> 292277026596-12-04T15:30:07.000Z (was epoch),
10_000_000_000_000 s -> 318857-05-20T17:46:40.000Z
civil 10_000_000_000_000 -> 318857-05-20T17:46:40,
-10_000_000_000_000 -> -314918-08-13T06:13:20, i64 extremes
* Don't build a year-318857 SystemTime unchecked in the logging test
Windows' SystemTime only reaches about year 30828, so
UNIX_EPOCH + Duration::from_secs(10_000_000_000_000) panicked before
timestamp() ran and failed the Windows test job. Build it with
checked_add and assert where the platform can hold it. The year-10000
case fits everywhere and stays unconditional.
* Name the 400-year range extension as the one exception to the time rule
The rule said never to hand-roll calendar math, but the range fix
(shifting by whole 400-year Gregorian cycles so dates past chrono's year
range keep their old output) is cycle arithmetic, so the rule and the code
disagreed. The rule now names that exception: the library still computes
month, day and time, and only whole cycles are carried in the year.
* Say the library computes month and day; time-of-day is plain arithmetic
Narrows the range-extension wording: the date library computes the
calendar fields, and splitting seconds into hours, minutes and seconds
is ordinary arithmetic, which is what the code does.
Review follow-up (CodeRabbit): zoomed in, the badge moves to the canvas'
top-left corner, where the info overlay draws its lines; with the overlay
on, the label was painted under its first line. The badge's top inset
now takes the overlay's extent as well as the filter pill's. The overlay
is split into its lines and an extent helper, laid out with the same
fonts, so the two can't disagree.
Test: zoomed_in_the_before_label_keeps_clear_of_the_info_overlay.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AbegtYaPuwqZ81pGfELsFK
Calls storytold/craft-common-actions/.github/workflows/sonarcloud.yml@main
with secrets: inherit. Adds SonarCloud badge to README where missing and
removes the redundant sonar-project.properties (config now passed by the
reusable workflow).
Review follow-ups for the Reference lifecycle fix:
- photo.setReference refuses an id that is not a photo id instead of
pinning the active photo; only an absent or null id means the active one.
- A Recently Deleted photo is refused with a message that says to restore
it (setReference and view.reference); the grid menu item is disabled for
it and any refusal is shown as a toast, not dropped.
- Reference view with no live pin releases its panes (windows, region and
pane textures, full capacity) like other views.
- A successful library switch leaves Reference for the grid; the Compare
pair is now cleared only on success, like the reference pin.
- One compare::live helper replaces four copies of the "exists and not
deleted" check.
- whats-new entry moved to 2026-10-21; checklist and ui-parity dates bumped.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The PR branch dropped it along with the PREVIEW_LIMITS import; nothing
here changes the default preview limit.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The web release now builds with craft-fonts too (web-craft-fonts), as VectorCraft's
does, so the published web app ships the Chinese and Japanese faces docs/releasing.md
promises.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The random-edit test now runs five seeds instead of one. A grid-mode change
re-reading every photo, and the group names growing unpruned, are now said in
the comments (the "a day or two at most" claim was wrong for capture-time edits).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Every catalog change gave the grid a new list of photos, and it read every
photo of it again: each one's date group (a lookup, a date parse and a
string) and its cell's shape. At 180,000 photos that was a 100 ms frame for
every batch an import added.
- catalog: Catalog::date_runs is split into date_group (one photo's own
group) and date_runs_of (the stack rule and the runs), which the grid
uses too.
- ui: GridCache keeps what it read of each photo of the list, position by
position. A new list that differs by the photos the catalog says an edit
touched is read again only for those; anything else (another view,
order or grouping, a stack) is read whole. The square grid reads no
shapes. A 16-photo batch at 181,749 photos: 101 ms -> 7 ms.
Co-Authored-By: Claude <noreply@anthropic.com>
The cancelled result is never used, but scan_files still checked each listed file's cached probe against the file.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The row read "1 folders, 1 files"; it now reads "folders: 1, files: 1" (all 13 catalogs).
`listed` is stored with Release and loaded with Acquire, so a reader that sees the listing over also sees what was stored before it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The scan lists the whole folder tree before it checks a photo. On a large
folder on a network share that takes minutes, and the scan's row showed
"0 of 64085" with an empty bar all that while: it looked frozen. ✕ did
not stop the listing either.
- engine: SyncProgress counts the folders and files the walk listed and
says when the listing is over; a folder note (walk::NoteFolder) now
answers whether to go on, and a cancelled scan answers no.
- ui: while the folder is listed, the row has an indeterminate bar and
reads "Listing folders: N folders, M files · folder" (all 13
catalogs); the dialog says the same; then the photos checked are
counted as before.
Co-Authored-By: Claude <noreply@anthropic.com>
When the scan finds nothing to import, relink, remove or read, the dialog
showed four greyed choices (two still ticked) and a Synchronize button
that started an empty job with an activity row. It now shows the folder,
"The library is up to date with this folder." and any Skipped lines, with
one Close and no Cancel (`only_shows`). `sync::confirm` answers
`{"upToDate": true}` and starts nothing, so `ui.dialog.confirm` and agents
get the same result.
Co-Authored-By: Claude <noreply@anthropic.com>
crates/ui-egui/locales/{cs,it,pl}-formats.json: kept the translations and added the track's new keys.
docs/parity-checklist.md: newer header line; revision rows from both sides.
docs/whats-new.md: both tracks' 2026-10-15 entries.
Held for the owner: #995 and #999 overlap, and #995's author offered on 10-12 to
close#995 once his commit was in #999. docs/parity-checklist.md: header keeps the
#1485 note and drops the #995 part.
aiongg