Files app candidates: host-native theming screenshots

Evidence class

Host-native, not board, not QEMU, not the riscv64 cross build. This captures the real x86_64-linux pkgs.portfolio-filemanager and pkgs.nautilus packages (substituted unmodified from cache.nixos.org — no patch, no override) running under Xvfb, with the exact runtime flags the board’s launcher wrapper (nix/shell.nix’s mkFilesAppLauncher) sets: GSK_RENDERER=cairo and GSETTINGS_BACKEND=keyfile pointed at a keyfile rendered by tools/theme_gtk.py. It proves the GSettings appearance mechanism itself works against a real GTK4/libadwaita runtime. It does not prove riscv64 cross-build correctness, Pixman/cairo renderer visual output on this board’s actual wlroots compositor, or anything about launch time, memory, or touch behavior — those remain board tasks (tasks.md 5.3).

Harness

xvfb-run -a -s "-screen 0 568x1000x24" dbus-run-session -- <app> <sample-dir>

with HOME/XDG_CONFIG_HOME pointed at a scratch directory containing .config/glib-2.0/settings/keyfile (the file tools/theme_gtk.py renders), XDG_DATA_DIRS covering gsettings-desktop-schemas and yaru-theme, then imagemagick’s import -window root after an 8s settle. dbus-run-session is only for this host harness’s convenience (Nautilus’s Tracker/GVfs calls resolve faster with a session bus present); the board’s own launcher does not add one — see the “found and fixed” note below for why that is fine.

Sample directory: Documents/, Pictures/ (empty dirs) plus notes.txt, photo.png, report.pdf (empty files) — enough to exercise folder vs. file icon rendering, not real content.

What this run found and fixed

The first attempt used ${pkgs.gsettings-desktop-schemas}/share on XDG_DATA_DIRS. Both apps rendered identically regardless of the keyfile’s color-scheme (byte-identical portfolio-dark.png/portfolio-light.png outputs), and gsettings get org.gnome.desktop.interface color-scheme under the same environment returned No schemas installed. nixpkgs does not install a package’s compiled GSettings schema at <pkg>/share/; its glib setup-hook installs each package’s own gschemas.compiled under <pkg>/share/gsettings-schemas/<name>/glib-2.0/schemas/ specifically to avoid cross-package collisions, and expects consumers to add <pkg>/share/gsettings-schemas/<name> (not <pkg>/share) to XDG_DATA_DIRS. Fixed by using nixpkgs’ own passthru helper, glib.getSchemaDataDirPath, in nix/shell.nix’s filesAppSchemaDirs rather than a hand-built path. Re-running with the fix: gsettings get correctly read back 'prefer-dark'/'Yaru-purple'/'Adwaita-dark', and the four screenshots below are visibly distinct dark/light renders. This is exactly the kind of bug host evidence is supposed to catch before a board flash — see portfolio-dark.png/portfolio-light.png below for the before/after (these four files are the fixed run; the broken run’s byte-identical pair was not committed).

Screenshots

Both apps: window chrome (headerbar, back/forward, search) renders and reflows correctly at the board’s 568px panel width. Dark/light switches the whole surface (headerbar, list background, text color) in both apps. Mime icons for the plain files (notes.txt, photo.png, report.pdf) show as broken/generic icons in Portfolio — shared-mime-info’s icon-name database was not on XDG_DATA_DIRS in this harness, a host-harness gap (not wired into the board’s launcher wrapper either yet) tracked as a follow-up, not a theme-fidelity defect: the folder icons and the overall Yaru variant select correctly.

Not covered here

• riscv64 cross-build output (docs/evidence/files-app/ has no cross-build screenshot yet; see tasks.md 2.2/2.3 for build status).
• The board’s actual Pixman/cairo-renderer visual output, launch time, or RSS — coordinator task, tasks.md 5.3.
• Whether an already-open window picks up a later theme change live (see design.md decision 5; this harness only ever starts a fresh process per screenshot).
• shared-mime-info wiring for correct per-file-type icons.