Bug 501220

This is a reopen of: https://bugs.kde.org/show_bug.cgi?id=499589. I can't edit its status, hence a new ticket.

SUMMARY
Justfification for reopen:

How many _popular_ AppImages (i.e. created by commercial entities who are doing the linux world a favor by offering a version of their software for the platform) has the KDE team tested this integration on to their satisfaction? Do you want KDE to seamlessly handle AppImages or do you want to force users to drop to the command line to figure out why AppImages are not working? Is KDE pragmatic or purist?

All of the following AppImages fail with the behavior described in 499589, or silently with some other failure. Please, try all of these for yourself and tell me that this is the user experience that KDE should be offering for these.

* Cursor
* Github Desktop [not 499589, but still should provide feedback]
* Bitwarden
* DrawIO
* Balena Etcher [missing FUSE]
* VSCodium

I accept the argument from the prior ticket that --no-sandbox is a special parameter ("special" meaning electron, so not exactly niche). However, that doesn't matter if say, 70% of AppImages _by usage_ have the issue (and let's face it, most people will likely not install AppImages of stuff that's already in the distro's repositories - so by definition, you're looking at software that's probably from outside of the Linux ecosystem).

The feature (KDE can open AppImages) is simply incomplete without feedback on why a particular AppImage failed to open, and my assertion is that a minimum fix should be to address this. Ideally it should handle common failure scenarios. You could do this by going through very popular commercial software and figuring out what the messages indicate, and add explanations. It doesn't have to be comprehensive; but Pareto will be your friend here. You could even go out of your way and handle some of the scenarios  (such as the need for --no-sandbox) for users. :)