Bug 389035 - When multiple copies of an app are installed from different sources (e.g. distro package version and Flatpak version), make each version clear
Summary: When multiple copies of an app are installed from different sources (e.g. dis...
Status: RESOLVED UPSTREAM
Alias: None
Product: plasmashell
Classification: Plasma
Component: Application Launcher (Kickoff) (show other bugs)
Version: master
Platform: Neon Linux
: NOR wishlist
Target Milestone: 1.0
Assignee: David Edmundson
URL:
Keywords: usability
: 390828 412641 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-01-16 05:02 UTC by Nate Graham
Modified: 2022-04-27 14:11 UTC (History)
9 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Two copies of the same app, each one from a different source (45.06 KB, image/png)
2018-01-16 05:02 UTC, Nate Graham
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nate Graham 2018-01-16 05:02:42 UTC
Created attachment 109900 [details]
Two copies of the same app, each one from a different source

See attached screenshot. I used Discover to install one copy of gedit from KDE Neon's packaging, and another from Flathub. Kickoff doesn't offer any distinction between the two, so it just looks weird and confusing, and I can't tell which version is going to open when I click on one of the two entries.

Perhaps we could mark each with its version and source to help differentiate them, e.g:
- gedit 3.18 (KDE Neon)
- gedit 3.26 (Flathub)
Comment 1 Pawel 2018-01-16 12:21:22 UTC
(In reply to Nate Graham from comment #0)
This is rather not related to plasmashell, but to packages developers. Name as we can see in Kickoff is in *.desktop file. If in both (from repository and from flatpak) is the same, we can see only the same name (i.e. gedit).
Comment 2 Nate Graham 2018-01-16 14:03:24 UTC
In this particular case, I would recommend that append some more information to the display beyond what the desktop file provides. It's not reasonable to ask packagers to do this, because the information about what source a package comes from is irrelevant in the common case that there's only one app installed. It's only once you have the same app installed from multiple sources that you actually start caring about which one is which.
Comment 3 Nate Graham 2018-01-24 20:26:13 UTC
So apparently with Flatpak at least, you can add something like this to your Flatpak recipe:

"desktop-file-name-prefix": "(Beta) ",

The version of Krita from the kdeapps Flatpak repo incudes a "(Nightly) " prefix[1], so if you installed Krita from Flathub and the kdeapps, everything would work fine because there would be two menu items like this:

- Krita
- (Nightly) Krita

This only works with Flatpak though. If you installed Krita from Flathub, and also from your distro, neither one will add a prefix to the name, so you'd end up with two menu items like this:

- Krita
- Krita

And you wouldn't be able to tell which one will run when you click on it.


[1] https://cgit.kde.org/krita.git/tree/packaging/linux/flatpak/org.kde.krita-nightly.json#n12
Comment 4 David Edmundson 2018-01-24 21:51:23 UTC
There's a cross desktop specification for how menus are made. 
https://specifications.freedesktop.org/menu-spec/menu-spec-1.0.html

Nothing about adding a suffix to a directory unfortunately.

We generate the menu from the xml menu in kservice code.
I'm not convinced there's much we can do too much on the Plasma side.
Comment 5 Nate Graham 2018-01-24 21:54:05 UTC
Perhaps we should brainstorm a workable approach then, because this is going to come up more and more as Flatpak and Snap become more widely used by normal users.
Comment 6 Alexander Mentyu 2018-01-26 08:28:45 UTC
There can be detection for various apps installation methods with appending small overlay icons on the bottom right side for particular apps in the menu - like for apps installed with Flatpak, Snap, AppImage, Wine, from sources, AUR, etc. - with different icon for each source or with single icon for all apps that are installed from non-system repos
Comment 7 Nate Graham 2018-02-19 21:50:27 UTC
FYI this issue was mentioned in http://www.ocsmag.com/2018/02/16/plasma-the-road-to-perfection-is-paved-with-bugs/


Overlay icons would be good, especially if we add those to Discover, too, so users can learn to recognize them.

I think also adding the version number would be good, since that's the key difference between them, and the only reason to install multiple versions of the same app in the first place.

So the menu would show the following:

[VLC icon badged with the distro package] VLC (2.8.1)
[VLC icon badged with the Flathub logo]   VLC (3.0)
Comment 8 probono 2018-12-27 22:02:58 UTC
The problem is broader than just showing which application comes from where. There should also a heuristic to determine which version should be used to open documents, and an easy way for the user to override it.

Some thoughts on this are contained in the broader problem description at
https://github.com/AppImage/appimaged/issues/30
Comment 9 dagobertram 2019-10-03 08:49:32 UTC
(In reply to Nate Graham from comment #5)
> Perhaps we should brainstorm a workable approach then, because this is going
> to come up more and more as Flatpak and Snap become more widely used by
> normal users.

Did some brainstorming already take place, yet? I think it is a problem, which is more important than ever. When I want to test different versions of software (through standard repo, Flatpak or Snap) then I need to be able to differentiate them easily. (To find out, if some bug has been fixed in the newer flatpak version, for example.)
Linux Mint partially fixed the problem some time ago in the Cinnamon menu and mentioned it on their blog: https://blog.linuxmint.com/?p=3766
Comment 10 Alexander Lohnau 2020-08-27 15:01:13 UTC
*** Bug 412641 has been marked as a duplicate of this bug. ***
Comment 11 Nate Graham 2022-04-27 14:08:32 UTC
*** Bug 390828 has been marked as a duplicate of this bug. ***
Comment 12 Nate Graham 2022-04-27 14:11:14 UTC
Unfortunately this isn't possible with the current version of the desktop file spec, which assumes that only one version of an app will be installed. When an app has multiple desktop files, there is a preference hierarchy with the highest level one (e.g. in your home folder) overriding lower level ones. The spec would need to be changed before this can be done.