| Age | Commit message (Collapse) | Author |
|---|
|
A real album (irregular.ninja/so.war.das) surfaced the bug: a Fujifilm
X100V whose battery died reset its clock to 2000-01-01, and every EXIF
timestamp on that roll was stamped with the bogus date instead of being
omitted. Trusting it at face value sorted that whole roll to the front
of the album, ahead of hundreds of correctly-dated 2020s photos.
EXIF years before 2001 are now treated the same as a missing date tag.
The no-date fallback also switches from source mtime to filename order,
since mtime is not reliable either -- bulk-copying/rsyncing an incoming
directory commonly rewrites every file's mtime to the transfer time,
unrelated to capture order -- while sequential camera filenames track
real shooting order even across a clock reset.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
|
Adds a new yes/no config setting (default no, preserving current behavior)
that orders the main album's photos by EXIF date taken (ascending) instead
of the default filename/shuffle order. Reuses the existing EXIF cache and
tag fallback chain (DateTimeOriginal -> DateTimeDigitized -> DateTime)
already used for tooltips/details/stats, so ordering never disagrees with
what those features show. Photos with no usable EXIF date fall back to
their source file's mtime, staying fully deterministic and crash-free.
CHRONOLOGICAL_ORDER takes precedence over SHUFFLE when both are enabled,
documented in album-photo-select.source.sh and docs/configuration.md.
Wired through the config registry (CONFIG_SPECS), validation, CLI flags
(--chronological/--no-chronological), --print-config, --dry-run,
--verbose logging, and shuriken.json generation metadata. Adds unit and
end-to-end tests covering default-off behavior, EXIF-date ordering with
shuffle precedence, and mtime fallback for EXIF-less photos.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
|
shuriken relied on GNU-only extensions (find -printf, stat -c, cp -a,
sort -R) and hard-refused to run outside Linux. Resolve each of the four
tools once at startup to a FIND/STAT/CP/SORT variable, preferring a
g-prefixed sibling (gfind, gstat, gcp, gsort) when present on PATH -
mirroring the $SED/$GREP/$DATE tool-selection pattern in the sibling
gemtexter project - so the same source runs unmodified on Linux, macOS,
and FreeBSD once GNU coreutils/findutils are installed there.
- src/lib/compat.source.sh: add resolve_gnu_tool + FIND/STAT/CP/SORT;
add a fast verify_gnu_tool_versions preflight (--version contains
"GNU") ahead of the existing behavioral probes, which now run against
the resolved variables instead of hardcoded tool names; split the
probes and error reporting into their own ~30-line functions.
- Replace the GNU-only find -printf / stat -c / cp -a / sort -R call
sites in photo-list, image, album-photo-select, metadata-cache,
config.staging, and random source files with the resolved variables.
POSIX-portable find/sort calls elsewhere are untouched.
- README.md: drop the "Linux-only" claim; document brew/pkg GNU
coreutils+findutils install steps for macOS and FreeBSD.
- tests/cli.sh: add coverage for the g-prefixed-sibling preference and
for the new --version-string preflight's error message, alongside the
existing behavioral-probe guard tests.
just build / just check-generated / just shellcheck / just test /
git diff --check all pass.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
|
collect_dry_run_page_plan re-derived page_count via the ceil formula and
redirect_count via a magic "*4+2", duplicating logic owned by
album_page_records (pagination) and render_page_view_redirects (redirect
files). The preview could silently drift from a real --generate.
Single source of truth:
- album_page_count_for_image_count (album-photo-select.source.sh) owns the
MAXPREVIEWS-per-page grouping count that album_page_records realises.
- ALBUM_REDIRECTS_PER_PAGE=4 / ALBUM_REDIRECTS_LAST_PAGE_EXTRA=2 +
album_redirect_count_for_page_count (album-render.source.sh) own the
per-page (4) plus last-page-extra (2) redirect tally that
render_page_view_redirects actually emits.
dry-run now predicts both counts through these helpers (no dist files
touched, side-effect free). Confirmed the real redirect count is
page_count*4+2, so output is byte-identical: partial-final-page (3 preview
pages / 14 navigation redirects) and empty album (0 / 0) unchanged.
Regenerated bin/shuriken; just test/shellcheck/check-generated all pass.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
|
Collapse the duplicated "find photos, error on empty, random_index by
ctx, return one" pattern into a single photo-list.source.sh exposing
list_photos <dir> and pick_random_photo <dir> <ctx>. Consumers in
album-photo-select, album-render, image-pipeline and stats-render now
call the shared helpers; _stats_load_background_photos keeps its caching
via a cached list_photos call rather than re-listing per filter page.
Per-call-site random_index ctx strings are preserved, so selection
semantics are unchanged. Sourced before its consumers in LIB_SOURCES
(Justfile + src/shuriken.sh); bin/shuriken regenerated.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
|
album-render.source.sh bundled four concerns that change for unrelated
reasons. Extract three focused siblings, leaving album-render as the page
orchestrator:
- album-tile-layout.source.sh tile_layout_for, build_tile_block,
build_subdivided_tile
- album-thumbnail-html.source.sh build_preview_thumbnail,
append_preview_grid
- album-photo-select.source.sh album_photo_files, album_page_records,
splash_photo_files, random_splash_photo,
randomphoto
album-render.source.sh keeps page assembly, the per-photo view/details
pages, navigation redirects, index/splash, and the job_pool_* plumbing.
Every function moved whole with no body/signature change. The
album_view_page_for_photo accessor and its private ALBUM_VIEW_PAGE_BY_PHOTO
map stay in album-render so the stats mini-album boundary is unchanged.
LIB_SOURCES (Justfile + src/shuriken.sh) sources the three new modules
before album-render. Regenerated bin/shuriken.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
