[BUG] AppImage crashes with "Failed to initialize GTK" on NixOS + Niri (Wayland)

Bug Description

The AppImage version of Handy fails to start on NixOS + Niri (Wayland-only compositor) with a GTK initialization panic. The same AppImage works fine on the same NixOS system under a GNOME Wayland session. The app never reaches its UI — the crash happens inside tao's GTK backend during gtk::rt::init.

This suggests the app relies on GTK resources / environment variables that GNOME sets up automatically (GSettings schemas, XDG_DATA_DIRS, GDK_PIXBUF_MODULE_FILE, GTK_PATH, GIO_MODULE_DIR, etc.), but which are absent or not propagated in minimal Wayland compositors like Niri/Hyprland/Sway. The AppImage bundles GTK3 and its own loaders/schemas under usr/share/ and usr/lib/, but the bundled copies are not found by the GTK runtime at init time outside a full desktop environment.

System Information

App Version: 0.9.6 (AppImage: Handy_0.9.6_amd64.AppImage)

Operating System: NixOS 26.05 (flake-based config)

CPU\GPU: Intel N150

Compositor: Niri (Wayland-only)

Logs

When launching the AppImage (either directly, or wrapped via appimageTools.wrapType2 in a Nix flake) from a terminal inside the Niri session with handy or handy --dubug commands:

thread 'main' (29881) panicked at /home/runner/.cargo/git/checkouts/tao-9f9ecfc9576f24d2/c3bee28/src/platform_impl/linux/event_loop.rs:217:53:
Failed to initialize gtk backend!: BoolError { message: "Failed to initialize GTK", filename: "/home/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/gtk-0.18.2/src/rt.rs", function: "gtk::rt::init", line: 141 }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

With RUST_BACKTRACE=full:

thread 'main' (30129) panicked at /home/runner/.cargo/git/checkouts/tao-9f9ecfc9576f24d2/c3bee28/src/platform_impl/linux/event_loop.rs:217:53:
Failed to initialize gtk backend!: BoolError { message: "Failed to initialize GTK", filename: "/home/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/gtk-0.18.2/src/rt.rs", function: "gtk::rt::init", line: 141 }
stack backtrace:
   0:     0x5ada40ea7015 - <unknown>
   1:     0x5ada4041e47a - <unknown>
   2:     0x5ada40ea658b - <unknown>
   3:     0x5ada40ea62aa - <unknown>
   4:     0x5ada40eceab1 - <unknown>
   5:     0x5ada40ecea69 - <unknown>
   6:     0x5ada40ecef7c - <unknown>
   7:     0x5ada4041e30b - <unknown>
   8:     0x5ada40423bb1 - <unknown>
   9:     0x5ada407861b7 - <unknown>
  10:     0x5ada4072d1a4 - <unknown>
  11:     0x5ada40711536 - <unknown>
  12:     0x5ada40367fb5 - <unknown>
  13:     0x5ada40366863 - <unknown>
  14:     0x5ada4036a528 - <unknown>
  15:     0x79394162b285 - __libc_start_call_main
  16:     0x79394162b338 - __libc_start_main_alias_2
  17:     0x5ada403658e5 - <unknown>
  18:                0x0 - <unknown>

I do not have any Handy-generated log files because the crash happens before the application reaches its own logging initialization — the process exits with the panic above before creating any entry in ~/.local/share/com.pais.handy/logs/.

What I've tried (none worked)

1. Running the raw AppImage directly: ./Handy_0.9.5_amd64.AppImage — same crash.
2. Extracting the AppImage and inspecting its contents — it bundles a full GTK3 stack including:
   • usr/share/glib-2.0/schemas/gschemas.compiled
   • usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache
   • usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/immodules.cache
   • usr/lib/x86_64-linux-gnu/gio/modules/libgiognutls.so
   • Full set of Wayland libs, libwebkit2gtk-4.1, etc.
3. Wrapping the AppImage via appimageTools.wrapType2 in a Nix flake and adding these as extraPkgs: gtk3, gsettings-desktop-schemas, glib-networking, wayland, libxkbcommon, dbus, webkitgtk_4_1, gdk-pixbuf, alsa-lib, pipewire, libayatana-appindicator. Still crashes.
4. Pre-setting the environment variables to point at the extracted AppImage contents:
   bash复制

   export XDG_DATA_DIRS="$extracted/usr/share:$XDG_DATA_DIRS"
   export GIO_MODULE_DIR="$extracted/usr/lib/x86_64-linux-gnu/gio/modules"
   export GDK_PIXBUF_MODULE_FILE="$extracted/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache"
   export GDK_PIXBUF_MODULE_DIR="$extracted/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders"
   export GTK_PATH="$extracted/usr/lib/x86_64-linux-gnu/gtk-3.0"
   export GTK_IM_MODULE_FILE="$extracted/usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/immodules.cache"

Still crashes with the same GTK init failure. 5. Tried both GDK_BACKEND=wayland and without forcing a backend — identical result.

Expected behavior Handy should start under Niri (and other minimal Wayland compositors like Hyprland/Sway) without requiring a full desktop environment, ideally by either:

Initializing GTK with an explicit fallback that works in compositor-only Wayland sessions, or Bundling and self-locating its GTK resources so they don't depend on the host session's XDG environment.

Additional context

I haven't tested under X11/XWayland and would prefer not to — Niri is a Wayland-only compositor by design. Other Tauri apps (e.g. SourceGit) seem to have similar reports on minimal Wayland setups, so this may be an upstream tao / Tauri Linux issue worth tracking at that level too. On the same NixOS machine, switching to a GNOME Wayland session and running the exact same AppImage works with no changes — confirming the issue is specific to the session environment, not the hardware or OS.