Downloading a new version of an AppImage program should prompt for an in-place "update"

[MMachado05]

Pre-submit checks

• I checked for similar issues beforehand, but could not find any. I could not add my proposal to any existing issue.
• I am going to take the time to to fill in all the required details. I know that the bug report will be dismissed otherwise.

Feature description

I've just installed the Krita 5.21 AppImage, with the 5.20 version installed and integrated already. I ran it, integrated it, but now I have two different versions, the newer of which, for some reason, doesn't have a desktop icon; I assume this might be because both programs are trying to "share" the same icon, but I don't know for sure.

Proposed solution

AppImageLauncher should have a method of prompting the user for an in-place "update," perhaps with a message like "You may have an older version of the program 'Krita (5.21.0)' on your system: 'Krita (5.20.0)'. Would you like to replace the old version with the new version?" And it could show a similar dialog box to normal integration, asking if you just want to run it this once without overriding anything, or if you want to replace the currently installed AppImage with the newer AppImage.

Alternative solutions you considered

At the very least the missing desktop icon should be fixed. Beyond that, The AppImageLauncher settings, as lacking as they already are, could perhaps have a button called "find duplicates" where it searches its directory for programs that may be duplicates of one another. When it finds them, it can list them for the user and ask which version they'd like to keep, or if they'd just like to cancel. However, I feel like this being added shouldn't negate the value of the auto-prompt, and instead could allow for a "don't ask again for this program" option in said auto-prompt, where a user could continue running either version without interruption, until they personally decide that it's time to remove duplicates.

Additional context

No response

[TheAssassin]

I do like your proposal of "in-place updating", but given the current algorithm, this is not going to work. The hash suffix is not a random value: it's a hash of the AppImage itself. So just "pinning" that value across updates is not going to do anything here. AppImageLauncher would likely just append the new hash upon an update.

The bug you describe is definitely not caused the way you think it is. The icons are linked strictly to every single AppImage using a hash. If one of them doesn't work, it's either a bug in the integration code itself or in your desktop environment. Unfortunately, you chose to use the feature template, not the bug template. Please create a separate bug issue.

Related to #547 (comment). CC @whysthatso

[MMachado05]

Hmm, if that's the case, could a new option in the context menu be added, such as "replace with other version"? It could open the list of AppImages currently integrated and ask you to select the specific one you want to replace with, without filtering for "update candidates" so to speak. Maybe to provide it any advantage over simply deleting the old version, some kind of "old version" cache can be made in case there's an issue for easy reversion.

And I apologize about the other bug; it seems to have resolved itself after a restart. I'll try to keep separate requests/bugs in separate issues from now on!