Bug 399530 - Display which backends/sources are represented in the ApplicationDelegate
Summary: Display which backends/sources are represented in the ApplicationDelegate
Status: RESOLVED FIXED
Alias: None
Product: Discover
Classification: Applications
Component: discover (show other bugs)
Version: unspecified
Platform: Other Linux
: HI normal
Target Milestone: ---
Assignee: Aleix Pol
URL:
Keywords: usability
: 401178 401778 402093 408212 410803 417940 420660 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-10-08 23:20 UTC by Nate Graham
Modified: 2021-04-07 19:38 UTC (History)
12 users (show)

See Also:
Latest Commit: https://invent.kde.org/plasma/discover/commit/933bc4efd516e05b4d00d797524cebc7d023d1f7
Version Fixed In: 5.20
Sentry Crash Report:

Attachments
Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description Nate Graham 2018-10-08 23:20:05 UTC 
For a year, I've been working on getting upstream software to standardize their AppStream IDs so that Flatpak and PackageKit apps will be properly de-duplicated in Discover.

The effort cannot be considered a success. I've gotten only about a dozen apps to play ball, and in some cases they did it wrong or used an ID different from the one on Flathub, so the ID is still different. Varying distro release cycles mean that a lot of distros still stil with old AppStream data. And of course Snap apps cannot be de-duplicated at all right now due to no AppStream ID being visible to us.

The result is that Discover users still see "duplicates" when they search for apps with more than one app backend installed. It remains a bad user experience. So I'd like to propose a UI change that I believe will bypass this problem rather than futilely fighting against it.

Instead of trying to de-duplicate apps from multiple backends by matching AppStream IDs, we instead show all the different instances of each app on the browse lists and search results, but with their sources (Flatpak, Snap, or distro package) indicated on the delegate. I think this will be much more friendly than trying and usually failing to de-duplicate apps.
Comment 1 Aleix Pol 2018-10-11 15:44:42 UTC 
I would rather not.
Comment 2 Nate Graham 2018-10-14 15:45:45 UTC 
OK, let's re-purpose this to track displaying the source on the delegate like we discussed  the other day.
Comment 3 Nate Graham 2018-11-19 20:46:58 UTC 
*** Bug 401178 has been marked as a duplicate of this bug. ***
Comment 4 Nate Graham 2018-12-08 04:48:08 UTC 
*** Bug 401778 has been marked as a duplicate of this bug. ***
Comment 5 Nate Graham 2019-08-13 16:25:30 UTC 
*** Bug 410803 has been marked as a duplicate of this bug. ***
Comment 6 Walter Lapchynski 2019-12-30 08:20:43 UTC 
At least in 5.16.5, it seems there is a "Source" field, so it sounds to me like this has been implemented. Were we intending some other change I'm not understanding from this conversation?

I will say the multiple entries confuse users that don't understand all the different packaging options. Discover is supposed to be "intuitive and simple" (https://userbase.kde.org/Discover#What_Discover_is), so it's not like grouping all the sources under one entry is at odds with the goals of the project. If all the sources are shown with separate install buttons next to them (and perhaps a "recommended" next to the distro package), that seems to also be consistent with the idea that Discover should "try to guide users through safe choices" (https://userbase.kde.org/Discover#What_Discover_isn.27t).
Comment 7 Nate Graham 2019-12-30 16:08:21 UTC 
Ideally, when an application is available from multiple sources, Discover groups them all into one entry. It already does this for many apps. However this grouping requires that Discover be able to identify all of the different sources of the same app as in fact the same app. To do this, it matches on the app's AppStream ID. When multiple apps have the same ID, Discover understands that they're the same app, and groups them.

Unfortunately, many app sources don't provide quality AppStream data, or override the app's own AppStream ID with a made-up one of their choice. Some apps don't provide quality metadata either. And so on.

This bug report is requesting a fallback mode that shows the source on each list item so that confused users can see for themselves where the app comes from even when the grouping functionality didn't work because of any of the above issues.
Comment 8 Walter Lapchynski 2019-12-30 18:11:43 UTC 
If you mean the source would be shown on each item on the list, rather than solely within the individual metadata when you select an item, that sounds like a great upgrade.
Comment 9 Nate Graham 2019-12-30 18:14:59 UTC 
Yep, that's the idea.
Comment 10 Nate Graham 2020-02-20 23:31:31 UTC 
*** Bug 417940 has been marked as a duplicate of this bug. ***
Comment 11 Nate Graham 2020-04-23 14:09:31 UTC 
*** Bug 402093 has been marked as a duplicate of this bug. ***
Comment 12 Nate Graham 2020-04-27 21:39:26 UTC 
*** Bug 420660 has been marked as a duplicate of this bug. ***
Comment 13 Aleix Pol 2020-06-16 00:42:29 UTC 
Git commit 933bc4efd516e05b4d00d797524cebc7d023d1f7 by Aleix Pol.
Committed on 16/06/2020 at 00:41.
Pushed by apol into branch 'master'.

Show an indicator when the source of the package isn't the default source

M  +16   -2    discover/qml/ApplicationDelegate.qml

https://invent.kde.org/plasma/discover/commit/933bc4efd516e05b4d00d797524cebc7d023d1f7
Comment 14 Nate Graham 2021-04-07 19:38:10 UTC 
*** Bug 408212 has been marked as a duplicate of this bug. ***