Bug 424113 - When specifying the --application CLI arg, if the application in question is already installed, show the page for source that it is installed from, not the default source (if they would otherwise differ)
Summary: When specifying the --application CLI arg, if the application in question is ...
Status: RESOLVED FIXED
Alias: None
Product: Discover
Classification: Applications
Component: discover (show other bugs)
Version: 5.19.2
Platform: Neon Linux
: NOR wishlist
Target Milestone: ---
Assignee: Dan Leinir Turthra Jensen
URL:
Keywords: usability
: 426404 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-07-11 22:48 UTC by Michael
Modified: 2022-12-09 06:16 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
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 Michael 2020-07-11 22:48:42 UTC 
SUMMARY

With Discover set up to have Flatpak/flathub providing apps, when it comes time to remove an app via Kickoff, Discover doesn't auto-select the proper source of the installed app, confusing the user.


STEPS TO REPRODUCE

1. Navigate to Kickoff -> Applications -> System. 
2. Right-click on Dolphin. Select "Uninstall or Manage Add-Ons".
3. Discover launches to the Dolphin app overview page.


OBSERVED RESULT

The button at the top says "Install", not "Remove", which was the original intention. On my system, Discover has the *Flatpak* source selected by default for Dolphin, even though I had installed Dolphin via the regular neon package repository. I have to click on the Sources drop-down and change the

  "flathub (Flatpack) - 20.04.3 (stable)" 

default item to the regular package repository item:

  "ubuntu-bionic-universe (KDE neon User Edition) - 4:17.12.3-0ubuntu1". 

Then the "Remove" button appears.


EXPECTED RESULT

Discover when launched in a "uninstall" mode should find which source has the item installed and select that for us automatically. The "Remove" button should appear instead of "Install", which doesn't make sense in this context.


SOFTWARE/OS VERSIONS

Operating System: KDE neon 5.19
KDE Plasma Version: 5.19.3
KDE Frameworks Version: 5.71.0
Qt Version: 5.14.2
Kernel Version: 5.3.0-62-generic
OS Type: 64-bit
Processors: 4 × Intel® Core™ i5-2467M CPU @ 1.60GHz
Memory: 7.7 GiB of RAM
Graphics Processor: Mesa DRI Intel® Sandybridge Mobile
Comment 1 Patrick Silva 2020-11-02 21:41:48 UTC 
*** Bug 426404 has been marked as a duplicate of this bug. ***
Comment 2 Nate Graham 2021-04-07 17:59:52 UTC 
This would be very difficult to fix correctly because Kickoff does not know what the source of an app is; it only knows the app's AppStream ID, which it passes to Discover. When you click the "Uninstall or manage add-ons" menu item, it launches Discover like this:

plasma-discover --application appstream://org.devname.appname

So Discover opens, and displays the app using its default backend.


There are two ways I could see that this could be fixed:


Option 1. Teach Kickoff about the differences between different app sources, and have it pass a command-line parameter to discover indicating the source, which Discover would then consume to display the correct source when it opens.

Downsides: Information about software sources lives exclusively in Discover right now; would need to move all of that into a framework or into Plasma, and turn it into a generic, re-usable library with a stable API, so that both Discover and Kickoff could become consumers of that API



Option 2: Make Discover prefer showing the source that an app is already installed from when opened with the --application flag

Downsides: does not and cannot handle the case where an app is installed from multiple backends; only works in the case where an app available from multiple backends has been installed from one and only one of them. ...Which is probably the common case, but still.


Ultimately probably only #2 is at all realistic.
Comment 3 Michael 2021-04-08 00:01:11 UTC 
Yes, option #2 seems to be the most realistic option, or at least the most intuitive operation that I would expect using this functioality.
Comment 4 Michael 2022-12-09 06:16:08 UTC 
This bug appears to be fixed in https://bugs.kde.org/show_bug.cgi?id=461664
Closed