# PixelPass AppImage

A "thin" AppImage: the gui-enabled `pixelpass` binary, a launcher (`AppRun`),
and the desktop entry + icon. Run `./build-appimage.sh` to produce
`pixelpass-<version>-x86_64.AppImage`.

## Why thin

`pixelpass` is an orchestrator — it links almost nothing (only `libpipewire`,
which is excludelisted because it must match the host daemon) and instead
**shells out** to `gst-launch-1.0`, `pactl`, and a player (`mpv`/`vlc`) found on
the host `PATH`. The GUI's graphics libraries (`libGL`, `libwayland-*`,
`libxkbcommon`, X11) are dlopen'd at runtime and are likewise on the AppImage
excludelist — every desktop already has a matching set. So there is nothing
useful to bundle, and bundling the graphics stack would only risk driver
mismatches. The AppImage therefore carries just the binary.

This also explains why PixelPass suits AppImage better than Flatpak: the
no-sandbox model lets the bundled binary freely spawn the host's `gst-launch`,
`pactl`, and player, which a Flatpak sandbox would block.

## Host requirements

The AppImage runs on any reasonably current glibc-based distro that has:

- **GStreamer + plugins** — `gst-launch-1.0`/`gst-inspect-1.0` plus base,
  good/bad/ugly, libav, and the PipeWire plugin (the binary tells you the exact
  package names for your distro if something is missing).
- **PipeWire** (with the PulseAudio shim, for `pactl`).
- **A player** — `mpv` (preferred) or `vlc` — for the viewer side.
- For X11 single-window capture: `xwininfo`.

These are the same dependencies the Arch package lists; the AppImage just spares
you the Rust toolchain.

## Caveats

- **Built on a bleeding-edge glibc** (CachyOS), so the AppImage requires a host
  glibc at least that new. For broad compatibility, rebuild on an older base.
- **Hardware encode (VAAPI `vah264enc`)** uses the host GPU driver; it can't be
  bundled. The software path (`--no-hwencode`, x264) always works.