Pane action toolbar: 4 of 6 icons render as broken-image fallback (Fedora/Bazzite, v0.1.19 AppImage)

[manuacl]

Summary

In the per-pane action toolbar (top-right of each pane), 4 of the 6 icon buttons render as the GTK4 broken-image fallback (yellow warning triangle) instead of their actual icon. The 2 remaining icons render correctly.

Affected icons

From rust/limux-host-linux/src/pane.rs (v0.1.19, ~L490-515):

Position	Icon name	Result
1	utilities-terminal-symbolic	❌ broken-image
2	limux-globe-symbolic	❌ broken-image
3	limux-split-horizontal-symbolic	❌ broken-image
4	limux-split-vertical-symbolic	❌ broken-image
5	emblem-system-symbolic	✅ renders
6	window-close-symbolic	✅ renders

All 6 buttons are created with the same icon_button(name, tooltip) helper and same .limux-pane-action CSS class, so the divergence is not in the Limux code itself.

Environment

• OS: Bazzite (Fedora 44 atomic), bazzite-nvidia-open:stable, NVIDIA driver 595.71.05
• Desktop: KDE Plasma 6 Wayland
• Icon theme: breeze-dark (inherits breeze, hicolor)
• Limux: v0.1.19 (AppImage, fresh install 2026-05-20, never worked since install)
• Launched with: GDK_BACKEND=x11 GBM_BACKENDS_PATH=/usr/lib64/gbm LIBGL_DRIVERS_PATH=/usr/lib64/dri __EGL_VENDOR_LIBRARY_DIRS=/usr/share/glvnd/egl_vendor.d (XWayland workaround for an unrelated fractional-scaling bug)
• Bug also present with native Wayland backend (i.e. without GDK_BACKEND=x11), so XWayland is not the cause.

What I checked / tried (no effect)

1. Files exist: All 6 icon SVGs are present on disk. The 3 limux-* are in ~/.local/share/icons/hicolor/scalable/actions/ (copied from the AppImage during install per the install steps in the project's hooks). The 3 freedesktop ones are in /usr/share/icons/breeze-dark/.
2. GTK debug (GTK_DEBUG=icontheme): all 4 failing icons appear under looking up icon NAME for scale 1 — i.e. GTK does look them up. No "not found" message.
3. Icon cache: gtk-update-icon-cache -f ~/.local/share/icons/hicolor/ — cache rebuilt, confirmed includes the 3 limux-* names. No effect.
4. Force Adwaita icon theme via ~/.config/gtk-4.0/settings.ini: gtk-icon-theme-name=Adwaita. No effect (likely overridden by Plasma's xsettings under KDE).
5. Override utilities-terminal-symbolic with the Adwaita version (placed at ~/.local/share/icons/breeze-dark/apps/16/utilities-terminal-symbolic.svg so it takes priority over the system Breeze one). No effect — still rendered as broken-image.

Note on SVG format

Adwaita's symbolic icons use the GTK-standard color="#bebebe" + fill="..." recolor mechanism. Breeze's symbolic icons use a Plasma-specific <style>.ColorScheme-Text { color: ... }</style> + class="ColorScheme-Text" + fill:currentColor pattern. The local limux-*-symbolic.svg files (shipped in the AppImage and copied to ~/.local/share/icons/hicolor/scalable/actions/ during install) use neither — they just use hardcoded stroke="#bebebe" or fill="#bebebe" on shapes.

However, since emblem-system-symbolic (Breeze format, same family as utilities-terminal-symbolic which fails) renders fine, the SVG format alone doesn't seem to explain the split.

System detail that might matter

Bazzite/Fedora atomic does not ship a libpixbufloader-svg.so (no SVG loader registered in any gdk-pixbuf loaders.cache). The AppImage also does not bundle one. Yet 2 of the SVG icons still render correctly, which suggests GTK4 is loading SVGs through librsvg directly (which is installed as librsvg2-2.62.0-1.fc44), not via gdk-pixbuf. Mentioning this in case it interacts with the bundled GTK4 loader logic.

Reproduction

1. Bazzite (or any modern Fedora atomic) with Breeze as the icon theme
2. Install Limux 0.1.19 AppImage following the install hooks (icons copied to ~/.local/share/icons/hicolor/scalable/actions/)
3. Launch — 4 of the 6 pane action icons render as broken-image fallback

Happy to provide more diagnostic info (full GTK_DEBUG=icontheme log, AppImage ldd of bundled libs, etc.) — let me know what would be most useful.

[manuacl]

Follow-up findings

After more testing tonight, the bug actually splits into two distinct sub-issues with different behavior:

Sub-issue 1: utilities-terminal-symbolic is XWayland-specific

• Under GDK_BACKEND=x11 (XWayland): renders as broken-image fallback
• Under native Wayland (no env override): renders correctly

This icon is provided by the system's breeze-dark theme at /usr/share/icons/breeze-dark/apps/16/utilities-terminal-symbolic.svg. The same SVG file works under Wayland but fails under XWayland in Limux's bundled GTK4.

Why this matters: I'm forced to use GDK_BACKEND=x11 on Plasma 6 Wayland because under native Wayland the embedded Ghostty terminal area renders completely black at any fractional scale (1.25, 1.5, …) — confirmed by testing both modes back to back. XWayland works around that, but trades it for this icon bug.

Sub-issue 2: The 3 limux-*-symbolic icons fail under both backends

• Under native Wayland: still broken-image
• Under XWayland: still broken-image

These are the SVGs bundled in the AppImage at usr/share/icons/hicolor/scalable/actions/.

I tried rewriting them locally using the Adwaita-style symbolic format that the working icons use:

<svg xmlns="http://www.w3.org/2000/svg" width="16" height="16">
  <g color="#bebebe" fill="#bebebe">
    <path d="..." />
  </g>
</svg>

(simple geometry, fill-only — no stroke, no inline <style>, no class= markers, group-level color="#bebebe" for GTK4 recoloring).

Then gtk-update-icon-cache -f -t ~/.local/share/icons/hicolor/ and full app restart. No effect — still broken-image. So the SVG format is not the cause for these.

Net effect on a Plasma 6 Wayland + fractional scale setup

• 4 of 6 toolbar icons appear as broken-image
• If I drop GDK_BACKEND=x11, the terminal area goes black at fractional scale — a worse trade-off
• The 2 icons that always render (gear, X close) are also from breeze-dark, so it's not a theme-wide failure

Happy to test any patch / debug build / specific env-var combo if useful.