[foxnne]

Follow-up to #621, #632, #647, #664. Reported by a Linux user.

What changes

On Linux the Window material setting listed Frost, Blur and Liquid Glass, then said "shown as Clear" and drew a clear window. Now:

• Every material is listed; one this platform cannot draw is greyed and not selectable, with a tooltip saying why (Linux: "Not available on Linux yet: needs compositor blur" for Blur where the compositor has none; Frost and Liquid Glass likewise; Windows: Blur and Liquid Glass; macOS before 26: Liquid Glass). The row shows the material actually drawn; when that is not the saved one, its tooltip says which is saved and why it is not drawn.
• Opaque is first, and the fallback never lands on Clear. A kind that cannot be drawn falls back to the richest glass below it (Liquid Glass to Frost on Windows and macOS before 26, to Blur on a blurring Linux compositor), else to Opaque. A clear window is drawn only when asked for. A fresh profile (Liquid Glass) on Linux without compositor blur is Opaque.
• The saved choice is never rewritten: a settings.zon shared with a Mac keeps .liquid, drawn as the fallback here.
• One place answers "can this be drawn here, and why not": backend/src/materials.zig (std-only, tested), from what the backend found at run time (Platform: OS, Liquid Glass, compositor blur). SDLBackend.materialKinds, materialAt and the new materialMissing read it; Entry.materialMissing is what the setting and the step command ask; the web offers every kind; a backend that says nothing offers Opaque alone. Linux blur (plans#27) only flips compositor_blur.
• The step command (fizzy.windowMaterialStep) steps from the kind drawn and skips what cannot be drawn. fizzy.windowMaterial still saves any kind (the tour's tape sets each), drawn by the same fallback.

Interpretation to check: "falls back to the first available" is taken as "richest glass below, else Opaque" rather than "always Opaque", so Windows and older macOS keep frosting by default. Making it always Opaque is a one-line change in materials.effective and Material.effective.

SDK impact

• None (core/material.zig's fallback rule changes; no boundary shape moved, test-sdk-version passes)

Verified

Unit tests: backend-materials-tests (availability per platform, the reasons, the fallback) and fizzy-material-tests (fallback order, never to Clear, Opaque listed first). The saved value staying is by construction (the fallback is computed each frame into core.material.publish, never written back) and covered by the existing demo test in tests/demos.zig.

Gates, locally on macOS: scripts/check-fmt.sh, zig build, zig build test, zig build test-integration, zig build check-web, zig build test-sdk-version.

• macOS: built and tested; the dropdown not looked at in a running fizzy
• Windows: CI cross-compile only
• Linux: not run; CI builds and runs test-integration there
• Web: check-web only

Review (code-review, medium)

Fixed: the platform probe runs once a frame (cached on the backend, cleared in begin); the step walks from the drawn kind; the saved-not-drawn tooltip shows whenever they differ; a stale doc comment; a one-line wrapper and a tautological test removed.
Left: a disabled row is still a menu item that highlights, as core.widgets.menuRow's disabled rows are (no disabled state in the dropdown's rows); the fallback rule lives in core/material.zig and backend/src/materials.zig, as the material enum already did, since the backend package can't import core; Entry.materialMissing needs a current dvui window, as every command that refreshes does.

Follow-ups

• A separate In-app material setting for the glass fizzy draws itself, stacked on this PR.
• Real Linux blur and frost: plans#27 (linux-blur), which flips Platform.compositor_blur / the Linux frost answer in materials.zig.

🤖 Generated with Claude Code