epaint's has_glyph compares face keys, so a glyph drawn by the replacement
face reads as missing. With no face in the stack covering egui's `◻`, Inter's
`?` becomes the replacement and Inter's `•` fails the check, which happens
once another test (the #1141 one) has loaded a system face without `◻`: the
fallback tries loaded faces first. Compare the drawn glyph with the
replacement glyph instead, as assert_drawn already does.
The Chinese UI fallback was chosen by probing 文, which Japanese faces
cover too. Fallback takes a face already loaded first, so after the
English interface had loaded a Japanese face for kana, switching to
Simplified Chinese reused it, and the simplified-only hanzi (选, 删,
层, 设, 页 ...) drew as boxes. A Simplified Chinese interface now probes
页, as wordcraft does for its interface font (storytold/wordcraft#248).
The handle was filled with the colour of its own track (both the field
background), so it only showed while hovered or dragged. It now takes the text
colour, in every scroll area.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
`interface_symbols_have_a_glyph_in_every_family` (01400f0) is red on main: it asks
`Fonts::has_glyph` per symbol, which answers "does this family resolve `c` to a face other than the
family's replacement face" - and the replacement face is the first in the chain carrying epaint's
PRIMARY_REPLACEMENT_CHAR ('◻'). Inter has neither a replacement glyph nor triangles, so in the
`medium` and `semibold` families that face is the weight face itself: everything it owns (the whole
Latin set, `•`, `›`, `·`, `▶`, `◀`, `●`, `○`, `⚠`, `…`, `×`) came back as "no glyph" and only the
characters it leaves to JetBrains Mono (`▸`) answered true. Rendering is not affected - the atlas
resolves through the same chain and does find the weight face - so the assertion was wrong, not the
fonts: the bundled Inter faces carry ten of the eleven symbols and JetBrains Mono carries all eleven.
The test now asserts what the wiring promises, from the definitions that were installed: each family
draws with its own first face and its chain reaches the symbol fallback.
Verified on Linux (the test is red before and green after) with cargo fmt --all --check and
cargo test -p effectcraft-ui-egui --lib theme::tests.
Inter and egui's built-in fallbacks have no glyph for ▸ (U+25B8), so the
command palette's "EffectCraft ▸ Settings... ▸ Appearance..." and every
"File ▸ Import" hint drew a box. JetBrains Mono, already bundled, has it:
register it as a symbol fallback for the non-monospace families.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Effect Controls painted effect headers with fixed dark fills (#2a2a2a,
#2f3a52 when active) under the theme's text colour, so on Light the effect
names were dark on dark (1.1:1). The Timeline kept the selected layer's
time-graph row, the A/V and switch wells, the time navigator, the work area
bar and the expression field on fixed dark fills too.
Those surfaces are now theme tokens (fx_header, fx_header_active,
tl_graph_selected, switch_well, tl_nav_bar, tl_work_area_bar, expr_bg,
expr_text) with the dark values unchanged and light ones for Light. The
expression editor's syntax colours come from the theme as well: on the
light field a darker set keeps every category, enabled/disabled
expressions, matched brackets and line numbers at 4.5:1 or better
(contrast test, with a negative control showing the dark set fails there).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QiAJeFttZp83Fh7YuzAR5f
apply_visuals pinned egui's theme preference to Light or Dark on every
apply. egui syncs that to the native window (ViewportCommand::SetTheme),
winit then gives the NSWindow an explicit Aqua/DarkAqua appearance, and a
window with its own appearance no longer receives the system's
ThemeChanged events, so Sync with System froze on the first frame's
appearance.
Our visuals now go into both of egui's styles (light and dark), and the
preference is System while the appearance mode is Sync with System, so the
window keeps following the OS; fixed Light / Dark modes still pin it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QiAJeFttZp83Fh7YuzAR5f
Cause: two things kept Arabic out of a layer name on Windows.
- Windows switches the keyboard layout with Alt+Shift. Releasing Shift
before Alt left Alt held alone, and the in-window menu bar (#279)
counted the release as an Alt tap: it took the keyboard focus, the
rename field closed, and the letters typed next were swallowed by the
menu bar. The Project panel's rename field lost them the same way.
- The UI fonts are Inter plus the CJK system fallbacks, so Arabic,
Hebrew, Indic and Thai names that did arrive (pasted, or from a
project) showed as missing-glyph boxes.
Fix:
- An Alt tap only counts when Alt went down with no other modifier
held, so Alt+Shift in either release order is no tap; a plain Alt tap
still focuses the menu bar.
- The UI registers installed system faces for Arabic, Hebrew, Devanagari,
Bengali, Gurmukhi, Gujarati, Tamil, Telugu, Kannada, Malayalam and Thai
after the CJK ones, the same way (native only; the web build has no
system fonts). A face covering several scripts is registered once
(Segoe UI: Arabic and Hebrew; Nirmala UI: every Indic script).
- The text engine's fallback tries each script's plain platform families
(Segoe UI, Nirmala UI, Leelawadee UI, Geeza Pro, Kohinoor, Noto…)
before any covering face, so neither the UI nor a text layer gets a
calligraphic face that merely sorts first.
- The Timeline's rename field registers `timeline.layer.<id>.nameEdit`.
egui 0.36 shapes each run of one face, so Arabic letters join and a word
reads right to left; it has no bidirectional layout, so the words of a
multi-word Arabic name (and mixed Arabic/Latin) still follow each other
left to right.
Tests: ui_inline_edit a_layout_switch_keeps_the_name_field_and_arabic_
names_are_kept (Alt+Shift both ways in the layer rename, Arabic typed and
stored; Hebrew/Devanagari/Thai in the Project panel; a plain Alt tap
still focuses File; failed before: the field closed), theme
installed_script_fallbacks_draw_arabic_hebrew_indic_and_thai_names
(failed before: replacement glyph for Arabic) and
arabic_words_are_joined_and_read_right_to_left, text
other_scripts_fall_back_to_a_plain_system_family and the script
classification.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
#402 made Effect Controls' rows compact and aligned, as After Effects
draws them, and also added thin separator lines between parameter rows
in Effect Controls and the Timeline, with a Settings > Appearance > Show
Parameter Row Separators preference. After Effects has neither, so the
lines, the preference and the Tokens field go; the compact rows, the
alignment and the automation ids stay.
Saved settings with the old key load as before (unknown keys are
ignored).
Test: ui_parameter_spacing keeps the row geometry, hit target and
nesting tests; the separator tests go with the feature.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Two things are one level deeper than the first pass at this review:
- Nine of the call sites that pass the resolved language are inside test functions, where `app`
is owned, so `crate::i18n::language(app)` needs `&app`. `cargo check --all-targets` (which
compiles the test modules as well) is what reported them; a check without it does not, which is
how they survived the first round.
- `clippy -D warnings` rejects the explicit `'static` on `const KANA` / `const HAN`: a const
already has one.
On this branch `cargo fmt --all --check`, `cargo check -p effectcraft-ui-egui --all-targets`,
`cargo clippy -p effectcraft-ui-egui --all-targets -- -D warnings` and
`cargo test -p effectcraft-ui-egui` (40 targets, 113 lib tests) are clean.
Review follow-ups on #312:
- `crates/ui-egui/src/theme.rs`'s `japanese_font_tests` still called `install` with two
arguments, so `cargo test` did not compile. Every call site now passes a language.
- The call sites passed the stored `general.language` preference. With the default `system`
that is `""`, which handed the CJK choice back to the environment locale — one macOS and
Windows usually do not set. They now pass `crate::i18n::language(app)`, the resolved
language, so Match System draws Chinese on a Chinese system.
- Changing Settings ▸ General ▸ Language only reached the fonts on the first frame.
`EffectcraftApp` now remembers the language its fonts were installed for and installs them
again when it changes, so the switch applies without a restart.
- Documented that `fonts::set_cjk_locale` is process-global: the Han preference therefore
applies to composition text as well as the interface chrome (docs/preferences.md and the
function's own comment).
Rebased onto main after #309 landed — `header.rs` gained an `install` call site in the
meantime, and the catalogs now resolve through `i18n::language`.
- `effectcraft_text::fonts::set_cjk_locale` lets the host say whose face should draw Han
ideographs instead of leaving it to the locale environment, and drops the fallback cache when
it changes. `han_order` reads that request first; the tag → order rule moves into the pure
`han_order_for`, so it can be tested without touching process state.
- `theme::install` now takes the stored `general.language` value and registers one CJK system
fallback per script in every font family, the interface's own script first: kana for Japanese,
a Han character for `zh-hans` / `zh-hant`, then the other script so names in it still render.
A face is registered at most once, and a machine with no CJK font installs nothing (the web
build installs nothing, as before).
- Before this the probe was always `あ`, so Han text was drawn by the Japanese face whenever the
operating system's locale was not Chinese: a Chinese interface, and Chinese file, layer or
template names on any locale, both got Japanese glyph forms.
- Tests: the tag → order rule (`zh`, `zh_Hans`, `zh-Hant-TW`, `ko`, `ja`, `en`, empty), and the
registration order plus once-only registration for a Chinese, a Japanese and an English
interface.
Each half of a keyframe glyph had a 1 px near-black border, so keys
that overlap read as a tangle of borders. Keys are now flat, as in
After Effects: each half is filled and edged in the key's own colour
(the hairline closes the seam between the halves), so overlapping keys
read as one shape. The Light theme's keyframe grey is darker so
unselected keys still stand out on its light time graph without the
border.
Test: keyframes_are_drawn_without_a_dark_outline (icons).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The menu bar's own menus (Edit has 30 entries) had no scroll area, only their submenus did, so
on a short screen Edit ran past the bottom of the window. The font menu was capped at 420
points and never moved up, the Preview panel's and the viewer's popup lists neither scrolled nor
moved, and the Timeline's Blending Mode and Expression Language submenus didn't scroll. egui's
scroll bars also only appeared while the pointer was over the list, so a list could only be
scrolled with a wheel or touchpad.
- widgets::popup_list: the one popup list behind popup_menu, the font menu, the Preview panel's
dropdowns and the viewer's popups: as tall as the window allows, scrolling beyond, moved up to
fit the window.
- widgets::menu_scroll: the same for menus and submenus (the menu bar's, Blending Mode, the
Expression Language menu, the viewer's Select menu).
- Scroll bars always show (solid scroll style), so they can be dragged.
- A first window that doesn't fit the screen is maximized: the 1680 x 1020 default on a smaller
screen is only shrunk to the monitor's size, so with its title bar it ran under the taskbar and
cut menus off at the bottom of the screen even when they fitted the window.
Test: ui_scrolling a_menu_taller_than_the_window_scrolls (Edit in a 520-point window scrolls
its last entry into view and it takes the click); overflows_screen unit test.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Project panel Clear (#95's focus routing) goes through invoke, so deleting
items that compositions use still asks first (M3.16).
- ui_project_delete: let a dialog finish egui::Modal's sizing frame before
clicking its buttons (#95 moved dialogs to egui::Modal).
- #71's i18n / theme tests clear the frame's texture delta; egui asserts on
unhandled deltas in debug builds.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A real Settings model in the engine (`engine::prefs`): serde, versioned, dotted keys
(`general.undoLevels`, `labels.3.name`), migration of older layouts, unknown keys kept,
persisted through a `ConfigStore` trait (platform config dir on the desktop; MemoryConfig
for tests; the web app can back it with localStorage).
- After Effects 2026 pages (General … Scripting & Expressions) as a schema shared by the
dialog, `prefs.pages` and docs/preferences.md (rows not wired yet are listed there and
kept in step by a test).
- Commands: prefs.get, prefs.set {key, value | values}, prefs.reset {page?}, prefs.open
{page?}, prefs.pages.
- Wired settings: undo levels, path point size, tool tips, layers at comp start / CTI,
default spatial interpolation linear, Home screen on launch, new project template,
rendering progress in Info, adaptive resolution limit, cache when idle, fast previews,
theme + UI brightness, label names/colours everywhere (Label menu, timeline, project,
render queue, viewer), label colour for handles, grid colour/spacing/subdivisions, guide
colour, safe margins, still footage duration, sequence fps, audio output device and
output mapping, layer / footage / preview cache budgets, default 3D renderer.
- Settings dialog: AE's left page list + right content, OK / Cancel (restores) / Previous /
Next, every widget with an automation id.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Brandon Thomas