mollusk
09a07f5303
build-appimage.sh produces pixelpass-<version>-x86_64.AppImage via linuxdeploy. PixelPass links almost nothing (only libpipewire, which is excludelisted) and shells out to gst-launch-1.0/pactl/a player on the host PATH, while its GUI graphics libs are dlopen'd and also excludelisted — so the AppImage bundles just the binary, AppRun, desktop entry, and icon (~13 MB, zero bundled libs). The no-sandbox model lets the bundled binary spawn the host's tools, which is why AppImage fits this orchestrator better than Flatpak. AppRun opens --gui when launched with no args and no controlling terminal (file manager / .desktop), and passes through otherwise so the CLI, interactive menu, and viewer all work. README documents the host-deps contract + the glibc-baseline and VAAPI caveats. Verified: builds to 13 MB; --version/--help work; the GUI launches cleanly on a live Wayland session via both --gui and the no-tty AppRun path. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
21 lines
798 B
Bash
Executable File
21 lines
798 B
Bash
Executable File
#!/bin/sh
|
|
# AppRun for the PixelPass AppImage.
|
|
#
|
|
# PixelPass is an orchestrator: it shells out to gst-launch-1.0, pactl, and a
|
|
# player (mpv/vlc) found on the host PATH. We prepend our own usr/bin so any
|
|
# bundled helpers win, but the host's tools remain reachable — that's why this
|
|
# app suits AppImage (no sandbox) better than a Flatpak.
|
|
HERE="$(dirname "$(readlink -f "$0")")"
|
|
export PATH="$HERE/usr/bin:$PATH"
|
|
|
|
BIN="$HERE/usr/bin/pixelpass"
|
|
|
|
# With no arguments and no controlling terminal — i.e. launched from a file
|
|
# manager or the .desktop entry — open the GUI. From a terminal, or with any
|
|
# argument (a ticket, --host, --gui, --repair, …), pass through so the CLI and
|
|
# the interactive menu both work.
|
|
if [ "$#" -eq 0 ] && [ ! -t 0 ]; then
|
|
exec "$BIN" --gui
|
|
fi
|
|
exec "$BIN" "$@"
|