With GPU rendering on and no graphics adapter at all (wgpu: "no GPU adapter among …", e.g. no
Vulkan loader: a `cargo run` outside `nix develop` on NixOS), every render ran on the CPU, much
slower, and only Settings ▸ Performance, Help ▸ System Info and `perf.gpuReason` said why.
The desktop app now queues one start-up notice per session once the device has been tried
(`gpu::ready()`, never blocking): "No graphics processor found: LightCraft renders on the CPU, which
is much slower. Details in Help → System Info.", on Linux with "On NixOS, start it from `nix
develop`." (→, not ▸: no installed font paints ▸.) `panels::notices::gpu_notice` decides from the
reason: nothing when the GPU was turned off (preference, LIGHTCRAFT_GPU, LIGHTCRAFT_GPU_BACKEND=off),
only a software adapter was skipped, or it failed later. Headless sessions and tests never show it
(`app.gpu_notice` is set by the desktop app only). Translated in all nine catalogs; one README
sentence in the Nix section.
Co-Authored-By: Claude <noreply@anthropic.com>
Fifth review round on 725eca27:
- develop.merge: a stated correction that is the photo's own, read in
any of the 8 frames, counts as not stated, so the photo's own is kept
and turned to the stated orientation. "The photo's own" is within 1e-5
per element, each matrix scaled so its last element is 1: rounding to
6 decimals moves an element by about 1e-6 at most, and corrections
1e-5 apart move no corner by more than about 0.2 px at 6000 px.
A copy of the settings read once and sent again after each change, or
written with fewer decimals, used to store the correction in the old
frame (15.5 px mean, 28.2 px max at 3200 x 4800).
- set_develop help: mentions the mode rule, and points agents to
Copy / Paste or Sync for copying edits between photos (settings JSON
from one photo carries that photo's correction).
- upright_transfer's module comment no longer says only the mode and
sliders move between files, as Lightroom does.
- Docs: the settings JSON rules in xmp-interop.md and whats-new.md.
- Tests, failing on 725eca27: a local copy sent whole three times,
re-rounded matrices (and corrections further away taken as given),
a sweep of 24,576 sends over every file orientation, read orientation
and later orientation, the same through MCP set_develop and through a
lightcraft-cli run script.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Each drag tick changed the edited photo's settings, so the filmstrip asked
for a new thumbnail render every frame. For an unedited raw shown with its
embedded preview, the thumbnail-level source had never been decoded, so each
of those renders decoded the whole raw (a 64 MP ARW: over a second), several
side by side, and the loupe's drafts queued behind them.
- The edited photo's thumbnail is not re-rendered during a slider drag while
it has one; it follows once the drag ends.
- A thumbnail of a photo whose preview-level source is decoded (the one in
the loupe) is cut from that source (SourceRef::Fit) instead of decoding the
file again; not when the photo has a denoised picture.
Co-Authored-By: Claude <noreply@anthropic.com>
The close button let eframe drop the window while AppKit's run loop was
still running; AccessKit restored the content view's class and AppKit's
Touch Bar KVO observer threw on the next display cycle. on_exit now ends
the process on macOS once settings and library are saved and background
work has stopped, as #444 does for Quit from the menu bar. Same fix as
storytold/gridcraft#117.
A debugging toggle (`view.frameRate`, `{show?}`, a checked item in a new Help ▸ Debug
submenu; LIGHTCRAFT_FPS=1 starts with it on; never saved). In the window's top-right
corner it draws frames per second and the worst over the last second, each frame's UI
CPU time against its time spent waiting (vsync, or the GPU), the latest whole-frame
and zoom-window render times, the render queue, renders thrown away as superseded
(Renderer::discarded), the GPU adapter and its memory, and a graph of the last frames
with a tick where a render arrived. It keeps the window repainting while shown and
logs the same numbers once a second (`fps-hud:`), so scripted drags can be measured.
Perf::host_frame_ms (the frame's CPU time as eframe reports it) is added as #1009
adds it, identically.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
eframe 0.36's App::on_exit takes the glow context as a second argument.
The macOS-only menu-bar Quit path still called on_exit(self), so the
0.7.0 macOS release job failed with E0061. Pass None; our on_exit ignores
it. macOS isn't built in CI, so only the release build caught it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
View > Right Panel (view.rightPanel, F8) hides the right panel and shows the one that was
there again (Edit when nothing was remembered; Crop, Remove, Masking and Red Eye end when
hidden and come back as Edit). View > Hide All Panels (view.allPanels, Shift+Tab) hides the
left sidebar, the right panel, the Presets column and the filmstrip; the next press brings
back exactly what was shown, so a panel that was already hidden stays hidden. Showing any
panel by hand while they are hidden makes the snapshot stale: the next Shift+Tab hides again
instead of resurrecting old state. Both commands take an optional show / hide parameter and
are checked in the View menu while they apply. The top bar and tool strip stay.
Shift+Tab is also egui's "focus previous widget", set when the pass begins and without
consuming the key; with nothing focused it focused the loupe. The shortcut consumes the key
and cancels the traversal. In a focused text field neither key is a shortcut, and Shift+Tab
keeps moving focus as before. On a Mac keyboard F8 is Play/Pause unless fn is held or
"Use F1, F2, ... as standard function keys" is on.
Docs: KEYC-PANELS is partial (Tab, T, F5 and solo remain; F6 / F7 are in PR #1078), KEYC-HELP
is done (F1), KEYC-RATING's missing list drops the already implemented [ ] keys, two View
menu rows are added, gap 28 shrinks, and the parity summary is refreshed with
cargo xtask parity --write (it was already stale on main).
The native menu leaves Shift+Tab to egui (no accelerator, so the macOS menu shows no key hint) and
the native_menu accelerator test lists it with the other keys egui handles.
After `lightcraft --control 7980` was running, the natural next thing to type
was `lightcraft-cli run --connect 7980 ui.inspect`. The CLI's argument parser
only consumed the value if it contained a colon (it was looking for a full
`HOST:PORT`), so `7980` fell through and was parsed as a command id, producing
`{"error":"unknown command `7980`","ok":false}`. The default address was used
behind the scenes, but only by coincidence matched `127.0.0.1:7980`.
The parser now also consumes a token that is all digits (a bare port) and
formats it as `127.0.0.1:<port>`. Non-numeric, non-`HOST:PORT`-shaped tokens
(e.g. `ui.inspect` after `--connect`) keep falling through so the existing
`--connect ui.inspect` form (use the default address, then run ui.inspect)
still works.
Two parser sites have the same shape — the global `--connect` in `cli()`
and the per-step `--connect` in `run_step()` — and both are updated.
Test: connect_bare_port_is_treated_as_loopback_port. cargo test -p
lightcraft-cli: 21 passed, 0 failed. cargo clippy -p lightcraft-cli
--no-deps clean.
Hands each selected photo's original file itself (a raw stays a raw: no
render, no copy, nothing added to the library) to the editor set in
Settings ▸ External Editing ▸ Other editor, e.g. DxO PhotoLab. Also on a
photo's right-click menu (Edit In).
- `photo.openOriginalInExternal {ids?, app?}` (UI command, menus.rs): up to
50 photos; demo photos and missing files are skipped with the reason; when
none has a file it fails saying why (toast + error, no panic). Enabled when
the active photo has a file and the host can start programs (not the web).
- Several photos go to one start of the editor (`Services::open_all_with`,
editors.rs `open_all_with`): a single-window editor such as DxO PhotoLab
drops the files that arrive while it is still starting when started once
per file. The system default ("" editor) still opens them one by one.
- Settings hint, translations of the two new toasts, parity rows
LR-EXP-PSD / MENU-FILE-PHOTOSHOP.
Tested by hand on Windows with DxO PhotoLab 8 (one and several raws).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Three boolean expressions clippy now wants simplified (pipeline's
normalize_wb, engine's learn_as_shot_wb, per nonminimal_bool), a
descriptor_copy only its #[cfg(unix)] test calls (dead on Windows), and
desktop_entries_give_their_program is unix-gated (Path::is_absolute
decides by the platform, and desktop entries run there). None change
behaviour; all four fail cargo xtask ci on this toolchain from main.
Co-Authored-By: GLM 5.3 Flash <noreply@z.ai>
On Wayland a window on a hidden workspace or minimized gets no frame
callbacks, so queued control requests waited 60 s and then ran when the
window came back, doubling retried work. The server now abandons a request
the app hasn't started after 5 s without a frame, says why, and the app
skips abandoned requests. Running requests keep the full 60 s. Also
as_chunks in spots.rs for the newer clippy lint.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
While no monitor profile is chosen, the Linux app reads the profile the
desktop assigns to the display in colord (org.freedesktop.ColorManager,
system bus, via zbus) on a background thread every 3 s, and shows
previews through it. With several displays it is used only when they all
share one profile; without colord the view stays sRGB. Windows' WCS
needs FFI and stays manual. Also satisfies clippy 1.99's
chunks_exact_to_as_chunks in spots.rs.
Sources: the colord D-Bus API documentation; own design.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
desktop_exec treats a freedesktop Exec path as absolute when it starts
with '/' on every platform (Path::is_absolute wants a drive letter on
Windows); fill_box uses as_chunks (clippy::chunks_exact_to_as_chunks);
LibraryLock::descriptor_copy is cfg(all(test, unix)) like its only test.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
AVIF HDR export takes hdrTransfer = pq | hlg (export dialog: HDR curve;
MCP export schema lists it). HLG writes CICP transfer 18 and no clli box.
The window logs whether it shows HDR; today always SDR (eframe configures
an 8-bit surface), with the platform / surface format / headroom / opt-out
rules unit-tested. Also satisfies clippy 1.99's chunks_exact_to_as_chunks
in spots.rs.
Part of #868.
Sources: ITU-R BT.2100 (HLG OETF, inverse OOTF with system gamma 1.2),
ITU-R BT.2408 (203 cd/m2 reference white at 75 % HLG); own design for
the display decision.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
On merge: the HDR histogram is applied in develop_reporting (#712 split develop), is skipped for
draft renders (a second render per drag tick), and HdrBins::bin clamps a hand-built split so it
can't underflow (test hdr_bins_with_any_split_stay_in_range).
- Settings ▸ General ▸ External Editing: the PhotoCraft location and Other editor
fields move from egui::TextEdit to TextField (edit menu, Esc restores).
- Edit In with the system default on Windows starts explorer.exe with the file
as one argument instead of cmd /C start, which read & ^ % | in file names as
shell syntax.
- psd::packbits walks the row with first()/get()/split_at_checked instead of
direct indexing and slicing.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BKWB9TCnvzJHV6xMLAj2J4
On merge: the XWayland default goes in front of the catch_unwind-wrapped launch (#951), and the
README's Linux section names the LIGHTCRAFT_WAYLAND=1 opt-out.
On some Windows machines FXC fails to compile egui's own shaders on DX12
("The parameter is incorrect. (0x80070057)" in egui_pipeline) and wgpu's
default error handler panicked. Each renderer (DX12, Vulkan, GL, glow) is
now probed with error scopes and a logging error handler before the window
opens; the one that works is remembered; a start that dies leaves a marker
and relaunches with the next renderer. LIGHTCRAFT_GPU_BACKEND=glow added.
Sources: own design.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Brings the branch up to date with main (#869 shared docking and the docs it
added); no conflicts.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
bflatastic