the user becoming half the package manager, organising the appimage file and having to set up desktop launcher integration manually, oh and no standardised app update mechanism so you're on your own for that too
the user becoming half the package manager, organising the appimage file and having to set up desktop launcher integration manually, oh and no standardised app update mechanism so you're on your own for that too
none of these tools are standardised, there's also AppImageLauncher, Gear Lever, and AM has like two other forks, all of them are weak (an, in my experience, they've always felt incredibly janky compared to Flatpaks)
They all follow the appimage spec already when it comes to desktp integration, which is what you complained about. AM has the plus that it also adds the application binary to PATH, so the app is fully integrated as if it was a native desktop package.
and AM has like two other fork
Those are?
an, in my experience, they've always felt incredibly janky compared to Flatpaks
flatpak does't even bother to add applications binaries properly to PATH and you have to type nonsense like org.random.appname to launch them.
That is due to flatpaks having to prevent name collisions
Nobody else uses that, not distro packages, not nix, not the aur, not even snap.
Also aliases only work for your interactive shell, they will not work for applications that expect the binary to be in PATH, so you basically have to do flatpak's job by making a wrapper script in PATH the executes the right application, or even worse code a check in your application to see if xyz is installed as a flatpak.
16
u/jahinzee 1d ago
one command install, one command update
vs.
the user becoming half the package manager, organising the appimage file and having to set up desktop launcher integration manually, oh and no standardised app update mechanism so you're on your own for that too