Add AppImage distribution

[Twig6943]

• Added protontricks logo from flatpak pkgs (named with reverse dns just like the flatpak id)

• Added StartupWMClass to the .desktop file (sharun complains otherwise)

• Added appimage ci (builds it off of the pkgbuild then converts it to appimage)

• Updated actions versions

[Twig6943]

@benjamimgois tested it and sait it worked like a charm

[Matoking]

Thanks for the pull request. I'm not familiar with AppImage packaging, so I've been investigating the space a bit.

Long story short: I don't think this PkgForge-based packaging approach is a good fit for my development process.

I've manually built, tested and published a small set of artifacts for each Protontricks release (mostly just a signed git tag, and a Python wheel and sdist). The latter are published to PyPI using 2FA. The lack of automation for version releases is on purpose and I'd like to keep it that way.

The PkgForge tooling relies on downloading build scripts from the main branch of several GitHub repos and running them in turn. This makes reproducing the same build environment more difficult compared to something like appimage-builder which is a Python package and can use any Python package management tool such as uv to lock down the build environment. The rest of the build tools in appimage-builder's case are provided by the distro packages (eg. Ubuntu, Arch); the packages there have a more established package testing and publishing process.

appimage-builder does have its own set of downsides:

• the project is at the moment unmaintained, albeit with several open pull requests fixing issues
• it downloads two sets of binaries from GitHub to build the app runtime without verifying them. Though that's less compared to PkgForge, and at least the other one should be GPG-signed.
• binary compatibility depends on the build platform and is not as broad as PkgForge's. But non-FHS support would also require additional support from Protontricks itself; I tested the PkgForge binary briefly with NixOS, and both Steam Runtime and non-Steam Runtime (--no-bwrap) paths crash immediately. By comparison, Ubuntu LTS is what Steam client supports and I think it's a reasonable baseline.

ProtonUp-Qt seems to be using it with no problems.

---

I tested the downstream AppImage and there were a few missing dependencies: I submitted a pull request at pkgforge-dev/Protontricks-AppImage#11.

[Twig6943]

I've manually built, tested and published a small set of artifacts for each Protontricks release (mostly just a signed git tag, and a Python wheel and sdist). The latter are published to PyPI using 2FA. The lack of automation for version releases is on purpose and I'd like to keep it that way.

I could just remove the workflow?

The PkgForge tooling relies on downloading build scripts from the main branch of several GitHub repos and running them in turn. This makes reproducing the same build environment more difficult compared to something like appimage-builder which is a Python package and can use any Python package management tool such as uv to lock down the build environment. The rest of the build tools in appimage-builder's case are provided by the distro packages (eg. Ubuntu, Arch); the packages there have a more established package testing and publishing process.

you could pin the commit of the scripts which shoukd work fine? as for nixos, most users of that gonna be using the native pkg anyways

I tested the downstream AppImage and there were a few missing dependencies: I submitted a pull request at pkgforge-dev/Protontricks-AppImage#11.

those were already known, we didnt bother to update that since we thoughr youd be down to merge this

Edit: I just realized we're not talking about the same dependencies so yea i could add those to this pr as well

With all of that being said if you still think it's not a good idea to use sharun i umderstand

[Samueru-sama]

The PkgForge tooling relies on downloading build scripts from the main branch of several GitHub repos

Repos? All scripts are downloaded from the main repo.

And you can easily pin the scripts to a specific commit if needed.

The rest of the build tools in appimage-builder's case are provided by the distro packages (eg. Ubuntu, Arch); the packages there have a more established package testing and publishing process

We are 100% the same in here.

binary compatibility depends on the build platform and is not as broad as PkgForge's. But non-FHS support would also require additional support from Protontricks itself; I tested the PkgForge binary briefly with NixOS, and both Steam Runtime and non-Steam Runtime (--no-bwrap) paths crash immediately. By comparison, Ubuntu LTS is what Steam client supports and I think it's a reasonable baseline.

The AppImage was a long pending request from an Alpine linux user (musl) which works.

pkgforge-dev/Anylinux-AppImages#238

appimagebuilder doesn't produce appimages that work in musl systems.

ProtonUp-Qt seems to be using it with no problems.

DavidoTek/ProtonUp-Qt#614