Yes, launching an app and having nothing happen is a bad UX, and users shouldn’t have to know about terminals and such to get debugging information.
BUT! Presenting information to the user in GUI form when this happens is surprisingly difficult to do reliably. How can the system detect that the app launches as intended? Believe it or not, there’s actually no way to know. This means guessing with complex heuristics that can break with “creatively designed” apps that do things like:
Running a helper executable that then immediately launches something else and then exits
Appearing in the system tray with no window
The more relevant solution here is for CachyOS to ship with both the Fuse2 and Fuse3 libraries. That way all AppImages will run, no matter what version of FUSE they require.
The best solution is to not use AppImages. AppImage as a technology cannot help but make assumptions about the libraries and library versions on the host system that it is incapable of satisfying.
Thus, the promise of “runs anywhere” is fundamentally a lie and cannot be fixed. Distros can do work to make it more likely that the unspecified dependencies of arbitrary AppImage apps are satisfied, but that’s just a “best effort” situation, and there is no guarantee.
Flatpak and Snap are the better technologies for getting apps outside of distro repos.
I was mostly thinking about the cases when the app does not run at all.
For example a script that references an interpreter in its “shebang” line that does not exist.
Or a binary executable for which the linker can’t find one of its libraries (has happened on KDE Neon recently because a .”so” symlink had the wrong version).
I like the idea of an “investigate” option as suggested by @jsswirus stdout/stderr of the app.
I don’t think we can reliably parse that to make suggestions but just using that as input into a search engine could be considered valuable.
I am unsure if we should consider apps that exit with a non-zero exit code though.
Exactly!
I was surprised that any distribution would specifically try to make it harder to run AppImages but maybe these are just collateral damage of an unrelated decision.
But anything else is risky. In the case here, the app did actually launch, it just exited immediately because necessary dependencies weren’t found.
We could try detecting whether the executable it launched exited with a nonzero status, and this would probably work for most apps. But there would always be edge cases where the executable is a helper program that launches the real program and exits nonzero for silly reasons, and in this case we’d show a dialog telling the user the app failed to launch when it appeared to be working fine.
I’m also not sure if this would work in the case where the executable specified in the desktop file is a helper like flatpak or snap.
Finally, the solution of including both Fuse2 and Fuse3 is pretty trivial. Arch (which CarhyOS is based on) packages both in the main repos and each one is only about 500k in size. Seems very weird to not just include both.
“actually launch” usually means the program got to the state where it executes its main() which it does not when missing a dependency.
I would expect that, e.g. QProcess does not transition from Starting to Runningbut from Starting to NotRunning in such cases.
Yes, as I said I would be weary to consider programs existing with non-zero exit code.
Hence the idea to concentrate on “not starting”.
If we wanted to consider non-zero exit code we would not say it failed to launch but that it started and exited with an error.
But again not something I would roll out without some considerable field testing, it at all.
That is indeed an interesting question.
The helper would start so we would consider this as a success but the command behind might not start. Not sure how likely that is though without somebody messing with the Flatpak’s internals or really badly packaged ones.
We could consider “whitelisting” flatpak and snap as known launchers and consider their non-zero exit code as launch failure.
Not sure if they usually just forward the app’s exit code or if they use this for their own purposes and simply discard the app’s codes.