Unfortunately it relies on distros to implement a solution but I would be fine with a popup that said “To ensure security, you’ll need to grant permission for this AppImage to run.” Then there would be a button that says “Learn How” and that button could simply direct to the gif or whatever.
Of course, it would be better if there was a more simple way of doing it . . . maybe a popup that asks for user password to automatically apply chmod in the background, maybe.
To clarify, when I said “it’s not difficult to do” I was referring to the action of making it executable not getting this warning to be implemented.
I didn’t miss the point at all. I have already expressed that the distro would need to implement some sort of functionality that addressed this issue. It’s not possible to force the distro to show a warning for the AppImages so if this were implemented it would unfortunately have to be done via the distros themselves.
My point about Windows and MacOS is that you still have to learn something in order to use them. Once this single concept of making executable is learned it doesn’t need to be learned again. I think you are exaggerating the size of the barrier that this is. It is a barrier but, in my opinion, it’s not “user-hostile”.
I agree that it totally is an issue but it’s an issue that requires outside implementation with distros in order to solve it. I wish that wasn’t the case but unfortunately it is. I suppose to best course of action for this is to the AppImage team to decide how they want to present a message that it needs to be done and then ask the distros to implement said message.
I would bet the AppImage team would love to be able to do that.
AppImages use the filetype “.AppImage” which is not recognized by most distros as a known filetype. The distros would need to recognize it as a filetype and invoke actions for that filetype based on whether it has permissions set correctly or not.
You’re right it’s not a novel idea but it’s also something the AppImage team does not have the ability to implement. This is something a distro has to want to implement and do so.
I don’t think many distros have even considered this as a feature to add because sadly many distro developers weren’t even aware of AppImages until a couple years ago and in some cases less than a year ago. I know one of the Fedora developers was discussing which was better Snaps or Flatpaks and someone suggested he look at AppImages and he said “what’s an appimage?”
Now many many more people are aware of AppImages but unfortunately many people still don’t understand how they work so distro developers may be aware of them now but might not be aware of this barrier for them. I suppose advocacy to these distro developers would be the best tactic.
With all that said, there is a workaround but I think it is kind of a messy workaround that I would rather fix the filetype issue than for this workaround to become the normal.
An AppImage can be set as executable and placed in a tar.gz archive. A user would download the tar.gz archive, extract it and the AppImage would be runnable without changing permissions.
There are many issues with this but most notable is that most open source software shares the source code of the software as tar.gz and having the same archive type to be the binary and the source code would be confusing.
This also would be an issue of having to teach people that you need to extract the archive . . . this would likely open up an archive software tool but they would still need to figure out to extract it.
Example: Etcher does it this way with a tar.gz archive. http://etcher.io