UPDATE_APP gains our accent (#e0368f, our colour in ArtCraft Launcher). The prompt draws it
on the UPDATE chip, the buttons and the What's new underline, and says "by ArtCraft"
(craft-update's default developer); #2646 gave it our icon.
craft-update is pinned to storytold/craft-libs main at 1065653e7 (#434).
header.rs, render_queue.rs: main's drag-toggle checkboxes report `.changed()`; the
Snapping, Notify and per-item Render check boxes keep this PR's AccessKit names and use
`.changed()`, the per-item one inside main's `add_enabled_ui`. The Render button keeps its
name with main's translated label.
effects_presets.rs: kept this PR's row_focus/nav_click and main's rows_before_presets;
main's reveal of Animation Presets with this PR's folder_row (nav, level), and the nav's
offset follows the scroll it moves; the search field keeps its name.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
craft-update's App gains icon_png here: the updater, the self-update helper and
craft-update's startup prompt all get it through crate::UPDATE_APP. The prompt draws it
once craft-libs includes storytold/craft-libs#434; AppImage menu entries get it now.
Clippy fixes for Rust 1.99 in untouched code (same logic):
- crates/gpu/src/tests/wgsl_grammar.rs
`init_gpu` built the compositor on the UI thread in the first frame, and eframe shows the window
only after that frame has painted. The compositor's ~235 compute pipelines take tens of seconds to
compile on a cold Metal shader cache (first launch, after an OS update, after an update that touched
a shader): about 40 s of no window at all, measured 39–41 s on an M2 Max.
On the desktop the compositor is now built on a worker thread (`gpu-compositor`), inside the same
`catch_unwind`, and attached when its result arrives; the worker requests a repaint, so nothing
polls. Until then the viewer composites on the CPU, as it already does without a GPU, and the
status line and `help.systemInfo` say "Preparing the GPU compositor…". A device failure during the
build discards the result; a thread that can't be spawned, and the browser, build in place as
before. `Hooks::before_gpu_build` lets tests hold or fail the build; `gpu_initializing()` exposes
the pending state.
Measured (release, cold cache, A/B interleaved): time to the window 39.0/40.9 s → 1.9/0.5 s, and
the control channel answers right after; with a heavy project opened at launch 38.3 s → 0.64 s
(first frame 88 ms after the app was created). Warm: 776 → 355 ms. The compile itself is not
faster; #1705 (effect kernels on first use) is the complementary half.
Tests: the interface draws, composites a CPU frame and reports the preparing state while the build
is held on a gate, then attaches the compositor; a build that panics leaves the viewer on the CPU
with the reason; the existing GPU/CPU parity test waits for the asynchronous hand-over.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Settings ▸ Import ▸ Reload Footage Changed on Disk used to spawn a stat thread every two seconds
from the UI thread, request a repaint 100 ms later to collect it, and request another repaint every
2 s in between, for every project with items, focused or not: the whole interface redrew on a timer
for footage that hadn't changed.
`footage_reload::Watcher` is one long-lived worker: the interface tells it what to watch (recomputed
when the project revision or the preference changes) and whether the window is in front; it stamps
the files every 2 s while the window is in front, every 10 s while another app has the front, at once
on focus regain and on a new set, and hands the stamps over — calling `ctx.request_repaint()` — only
when one differs from its last look. Nothing watched means the thread sleeps. `apply_stamps` and the
reload semantics are unchanged; `start_scan`/`poll_scan`/`Session::footage_scan` are gone. No new
dependencies: the stat loop is also what footage on a network share relies on, where FSEvents would
not report another machine's writes.
Tests: the watcher wakes the interface for the first stamps and for each change and never for an
unchanged file; behind another app it rests until the window is back; nothing watched is nothing
stamped and a new set is reported whole (and dropping it ends the thread); the host test
`the_watcher_notices_a_footage_file_changed_on_disk` saves a PSD from "another app" and sees it
reloaded once.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Conflicts: crates/ui-egui/src/menus.rs (upstream split it into menus/{bar,commands,entries,frontend,invoke,shortcuts,tests}.rs) and panels/settings.rs (ComboBox is now craft_ui::ComboBox).
- menus.rs: took upstream's slim module; re-applied the branch's two hunks in the new locations: nudge() now also skips Effects & Presets and Render Queue (menus/invoke.rs), and Enter is left to those panels in handle_shortcuts (menus/shortcuts.rs).
- panels/settings.rs: kept the branch's accessibility lines (shown_name, value_text) on top of craft_ui::ComboBox.
The accessibility audit BASELINE still matches the measured findings.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Conflict: docs/ui-parity.md (Estimate). Kept main's 60-110 h total
without the multi-monitor line and this branch's accessibility figure
(12-25 h, first slice done).
Adapted to main's shared docking layout (#2432):
- tests/ui_accessibility_audit.rs: Preview now gets a short frame at the
top of the right column and its controls below it stay in the tree,
counted against the panel underneath. The harness closes Preview, and
the per-panel pass closes it again after its own scenario. The
not-yet-fixed BASELINE numbers are re-measured in the new layout
(panels are taller, so more controls are visible); the fixed panels
stay at zero.
- tests/ui_effects_presets_keyboard.rs: the taller Effects & Presets list
now draws the starred Gaussian Blur row in Blur & Sharpen, so the
closed-Favorites check counts Gaussian Blur tree items (at most one)
instead of requiring no "Remove from favorites" star at all.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Resolve conflicts for the egui 0.37 migration: Id::unique ids, kept the
accessibility names and roles; stop giving unnamed check boxes, twirls and
toggles a role so the kittest accessibility check passes; refresh the audit
baseline.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
finish_ime after a body drawn before the Viewer cleared the preedit and
made the Viewer's publication a new context, so a window with another
group before the Viewer interrupted the composition every pass. Each
native window now counts its bodies from the layout and publishes once
its editor has recorded its geometry, or after its last body. A window
that drew fewer bodies than counted publishes after every body in its
next pass.
Keeps the worker's failure visible instead of leaving the prompt installing, repaints while a check runs, and no longer calls process::exit past the unsaved-work prompt.
Integrate `craft-update` pinned to storytold/craft-libs fe61243 to check for
updates on startup, display the standard suite update modal with changelog notes,
and support one-click in-app updating and restart.
Ref: storytold/craft-libs#319
On macOS rfd put an unparented sheet on AppKit's main window, which after a
click in a floating panel's OS window is that window. With the sheet holding
the keyboard no app window was focused, so craft-ui hid the floating window,
the sheet ended without answering, and later sheets queued behind it: Save As
flashed and closed, and Cmd-S did nothing after. The commands' dialogs now
open at the end of the frame with the main window as parent (macOS; Linux's
portal dialog stays unparented). While one is up the dock area blocks
floating OS windows, as for a modal dialog, and a dialog that ends without
answering never leaves them blocked.
craft-ui's native-windows feature is on for every non-wasm build. Keys and
dropped files from a floating window reach the main window's next frame, and
while a modal dialog is open the dock area blocks input in floating windows.
Move Panel to Main Window docks the panel again. The web, Wayland and embedded
viewports keep floating windows in the main window.
Every craft-libs crate and the hayro-syntax and hayro-jbig2 patches are
pinned to storytold/craft-libs 2869b8cc. The workspace is a craft-ui
Workspace<PanelKind>: craft-ui draws the frames, tab strips, stacked
panels, floating windows and drop previews and owns the gestures.
EffectCraft keeps PanelKind, its built-in workspaces, the panel bodies,
the Timeline's comp tabs, viewer locks and the panel menu in each group
header, and the rule that no move or float empties the docked area.
window.dockAction applies craft-ui Actions; craft-ui's window.panel.*
commands, ui.dock and ui.dock.reset parse as DockCommand. Saved
workspaces are version 2 snapshots of craft-ui Workspaces; an earlier
file loads as the default layout and is left untouched.
Reconcile main 991904888a and preserve the reviewed lifecycle, IME, rendering and lockfile changes.
Formatting, strict lint, layers, assets and WASM passed. Full CI retained 3,961 passes, 14 baseline-matching GPU failures and 31 ignored executions. The local review commit has explicit approval to retain these documented failures; native/browser acceptance and paired app performance remain open.
settings.rs: keep upstream's measured page-list width, text_fit and
translated page titles, and the PR's per-page ids, list-item roles,
keyboard focus and focus ring.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
OK runs layer.newPrimitive, which switches a Classic 3D comp to Advanced 3D in the same undo step. The dimension fields are the Geometry Options the engine builds for the chosen type.
Looking up to the whole RAM preview for uncached frames let the workers spread over the preview
while the playhead waited. On the GPU each worker then built a Classic 3D atlas for its own set
of layers, and on a cold start of the #1812 project the device ran out of memory far more often
(first pass 1-56 % of real time instead of 63-81 %). The window now keeps its old width but
starts at the first frame ahead that isn't cached, so a loop or a restart still renders on at
once.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The playback prefetch only looked ahead*3 frames (96 with 16 workers) for uncached frames.
After a loop or a restart from the start those were all cached, so the workers stood idle until
the playhead came within that window of the end of the cached run, then the preview stalled.
A playing preview now looks as far ahead as the RAM preview holds (and the range spans) for
the next uncached frames, still queuing at most ahead at a time; eviction already spares the
frames the playhead reaches first (#595).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Resolve conflicts in the Effects & Presets panel, the arrow-key nudge and the
docs; update two a11y tests to the prefs-based favourites.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Under load the first frame could take longer than STARTUP_WAIT to be
cached. The start then gave up, started the sound on that uncached
frame, and the stall path stopped it in the same step, so the opening
played silently.
STARTUP_WAIT (2 s) now counts from when the first frame is cached, and
only bounds the wait for the frames ahead. A new STARTUP_LIMIT (10 s
from Play) still ends the wait for a first frame that never gets cached.
The sound is never started on a frame that isn't cached: the preview
goes on as a stalled one does, and the sound starts once frames are in.
Tests (ui_audio_scrub): a first frame held uncached for 3 s still gets
its sound from frame 0, and the device keeps playing (fails on the
previous commit). The two give-up tests now check that no sound is
started and dropped.
rfd's Linux backend goes through the XDG desktop portal, and a blocking
`rfd::FileDialog` leaves the main thread waiting on the portal's answer
without pumping winit's events: while the Open dialog is up the window stops
answering the compositor, which offers to force-quit the app ("EffectCraft is
not responding"), until a file is picked.
The non-blocking host hook for the commands' dialogs (`rfd::AsyncFileDialog`
on a worker thread, run when the dialog closes) was macOS-only since #511.
Install it on Linux too. Windows keeps the blocking pickers (its dialog pumps
its own messages), and the panel buttons' pickers (Settings, effect file
pickers) are unchanged.
Checked headlessly against a mock XDG portal: with the hook the main thread
stays in the event loop while a worker blocks in the portal wait, `ui.inspect`
still answers 7.5 s after the dialog opened, and an answered dialog runs
File ▸ Import; without it the main thread itself blocks in the portal wait and
the app answers nothing until the dialog closes.
Co-Authored-By: DeepSeek V4.1 Flash Free <noreply@deepseek.com>
ui_accessibility_audit walks the AccessKit tree and counts unnamed or roleless controls per panel (zero required for Project, Effects & Presets, Settings and the Render Queue; a ratchet for the rest). Rows are named tree items with selected / open state, the page list is a list with positions, controls carry label and value, the lists take the arrow keys, Home / End, Enter and Space, popup lists take the focus when they open. ui_contrast checks the theme tokens against WCAG 2.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
The startup hold waited for the current frame to be cached before
anything else, so a frame that can never be cached held the first frame
for ever: a zero RAM preview budget, or a single frame larger than the
budget (which the comp-size estimate misses for Extended Viewer frames).
It now gives up at once when the budget can't hold even one comp-sized
frame, and otherwise after STARTUP_WAIT (2 s from pressing play): the
sound starts from the first frame, and the preview goes on as a stalled
one does. frame_bytes() is factored out of frames_that_fit() for it.
Tests (ui_audio_scrub): with a budget of 0 or half a frame the sound
starts on the first step; with an Extended Viewer frame larger than the
whole budget (the estimate says one fits) the first frame holds for about
two seconds, then the sound starts. Both wait for ever on the previous
commit. The Extended Viewer setup is now shared by its two tests.
The start held the first frame until `ahead.min(fit)` frames were cached,
which could never happen in two cases, holding it for ever:
- the prefetch requests offsets 0..min(ahead * 3, fit - 1) from the
playhead, one frame fewer than that when the RAM preview limits it, and
with the playhead held nothing else requested the last one;
- `fit` counts comp-sized frames, but Extended Viewer frames render
larger, so fewer of them fit in the budget than it needs at once.
It now waits for startup_frames(ahead, window, budget, frame bytes):
ahead, no more than the prefetch window requests, and no more than fit
in the budget at the size the first frame really rendered at, at least
the current frame.
Tests: startup_frames unit cases (a 4-frame budget needs 3; a 160×120
comp's 320×248 Extended Viewer frames need 2); ui_audio_scrub starts from
a cold cache with budgets of 2, 3, 4, ahead - 1, ahead and ahead + 1
frames, with and without a device, and with Extended Viewer frames larger
than the comp: each leaves its startup, from frame 0 (both hold the first
frame for ever on the previous commit). Also: a device whose start fails
plays the picture; a device that consumes the sound moves the picture on
and a stall still stops it; the 30 s preview starts without caching the
whole work area; Stop after a step of preparation never opens the output.
Cause: a preview with sound and video, without Cache Before Playback,
held its sound while the playhead advanced silently through frames as
they rendered, and started the sound at the frame it had reached once the
frames ahead were cached or rendering had kept up for a quarter second.
So the opening (about the first third of a second) was never heard, and
those frames played silently. With Video off, or Cache Before Playback,
the sound started at the first frame.
Fix: starting such a preview now holds the playhead on its first frame
while the frames ahead render (the prefetch window, at most what fits in
the RAM preview: not the whole work area), then starts sound and picture
together from that frame, the sound's clock driving the picture. Without
an output device the picture plays from that frame on its own clock. A
stall later on still stops the sound and catches up silently. Stop clears
the startup state.
Tests (ui_audio_scrub): the two startup tests no longer accept silent
frames first: the playhead must hold frame 0 until the sound starts, and
the sound must start at frame 0 (also for a 30 s work area, without
caching it all). A tone lasting only the first 100 ms after a start at
0 s and at 1 s reaches the output device. Video off still starts at
once; no device plays the picture; Stop while preparing leaves nothing
playing. The three startup tests fail on the previous code (the playhead
had moved on to frame 1, silently).
bflatastic
Dylan M. Taylor
Jason LukerandClaude Fable 5.1
tylerjenningsw
vangel76andClaude Sonnet 5.5
aiongg
skylar taylor-barrick
dedandClaude Opus 5.5
dorfee
Madhav AgarwalandDeepSeek V4.1 Flash Free
Brandon Thomas
FredApps