AppImageLauncher: Strategy for duplicate entries in launcher

In some cases, there might be duplicate entries in launchers, which is annoying for the user, as it’s impossible to differ between those, especially when they have the same icon as well.

This happens every time two desktop files have the same Name= entries. Situations in which this might be the case involve:

• The user installed an app via traditional package management, and integrated an AppImage for the same application.
• The user integrated multiple versions of an application.
• Combinations of these examples.

This is especially annoying in cases where there’s multiple AppImages for the same app involved. As the AppImages are all single files and technically independent from each other, you can’t just “replace” the old version with the newer one. Also, due to the lack of easily available version information (there are so many versioning systems there is no good way in supporting them all, hence AppImage doesn’t have any versioning support), one can’t just display the version numbers in the launchers, to allow a user to differentiate between different versions.

There is no really good method to detect “collisions”, as I’d call them. We need to compare the Name= keys of all existing desktop entries. Then, we can “resolve” these collisions.

Strategies to solve a collision:

• Inform user that the entry has been created for an AppImage. We could append e.g., [AppImage] to such entries (full example: Firefox [AppImage]). This would solve collisions of AppImages and system apps. Also, it’s a little more transparent to the user.
• Allow AppImage creators to add a “version information” to their AppImages. They could add the version to the Name key already, sure, but that doesn’t allow us to detect conflicts any more. We might want to ask users to “remove” old versions one day, and we can’t detect collisions any more, as we’d need to support their versioning scheme in order to parse it out of the Name= entry, which could then be compared again. Therefore, we should offer them a custom key, e.g., X-App-Version which they can set that is then appended to the Name= entry on integration. When running a collision detection check, the value of that key can be removed from the patched Name= entry, and we have the original value again. We could even store the original Name= entry in such a key on integration.
• File managers have had a solution for duplicate files for decades: simply append a monotonically increasing number to the Name= key on collisions. Of course, this is the worst of all these solutions, as it’s less meaningful, but it provides a method to create unique Name= entries, which are easy to memorize for users, as this is a well known method for users which they know already from their file managers.

Parts of this issue need to be discussed in AppImageKit/libappimage upstream (e.g., appending [AppImage] to AppImages’ entries is something that should be performed consistently across all AppImage tools, if we decide to implement it).