Bug 390911 - While updating, app/package list should sort by completion percentage
Summary: While updating, app/package list should sort by completion percentage
Status: RESOLVED FIXED
Alias: None
Product: Discover
Classification: Applications
Component: Updates (interactive) (show other bugs)
Version: 5.12.2
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Aleix Pol
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-02-22 16:43 UTC by Nate Graham
Modified: 2018-07-25 12:12 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Not quite (255.18 KB, image/png)
2018-02-27 04:34 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-02-22 16:43:30 UTC
Right now, it can be hard to tell that anything is happening during an update operation, especially when there are a lot of packages to update. The currently updating packages may be much farther down in the list, so the packages that are visible may not be changing at all. It can cause a sense of user unease; "Is Discover actually doing anything?"

This issue would be alleviated if the whole list became sorted by completion percentage while updating. That way the top of the list would always show the currently updating packages. This would give the user a strong sense of action, and show that Discover is doing something.
Comment 1 Øystein Steffensen-Alværvik 2018-02-22 18:53:44 UTC
This was something I questioned when I first used Discover to update. I still scroll down the list just to check what Discover is doing.

Users need to be more confident that Discover does what they told it to do, without needing to investigate.
Comment 2 Aleix Pol 2018-02-23 16:05:29 UTC
Git commit 2bddf51549db15130c2e96865fb52be31f338df1 by Aleix Pol.
Committed on 23/02/2018 at 16:03.
Pushed by apol into branch 'Plasma/5.12'.

Provide an alphabetically sorted list for updates

Should be more or less sequential, the backend will still choose the
most technically adequate installation order.

M  +3    -1    libdiscover/backends/PackageKitBackend/PackageKitUpdater.cpp
M  +3    -1    libdiscover/resources/StandardBackendUpdater.cpp

https://commits.kde.org/discover/2bddf51549db15130c2e96865fb52be31f338df1
Comment 3 Aleix Pol 2018-02-23 16:08:06 UTC
I see the issue, I'm not sure it's good design to show UI jumping around. Maybe we should consider having a dedicated display to show updates again.

See that patch, should alleviate the issue.
Comment 4 Nate Graham 2018-02-23 16:12:58 UTC
The "jumping around" issue would be alleviated if the list items can animate their movement. Is that possible? Otherwise I think this is still a win in the interest of presenting useful information, even if the list items jump around. I'll try out that patch with my next big batch of Neon dev unstable updates.
Comment 5 Nate Graham 2018-02-27 04:34:25 UTC
Created attachment 111037 [details]
Not quite

Did a big update with Discover built from git master (after merging Plasma 5.12), and it's still not what I'm looking for here. See attached screenshot.

Sorting by completion percentage would ensure that you're always looking at something that's happening and you can tell that there's progress. We still don't quite have that here.
Comment 6 Michał Dybczak 2018-03-26 16:22:40 UTC
I also find this a big issue and I really thought once that Discover got stuck or something.

As to solution, a usual update bar and "show details" list with "GUIed terminal output" (Octopi or Pamac do that correctly) would do the trick but that's just one of many possible solutions.

I think that packages to update shouldn't be tied to their own progress bars like it is now. Upon hitting "Update" should open a new update area (progress bar, info bar or whatever) showing what it's doing. Let the package list be the list. This joined functionality is not working well in that case.

I frankly doesn't understand how it works. In terminal output is very clear, at least on pacman side (Arch based systems) so we get shown each package and their download progress bar one by one and once it's done, similar thing for update progress and additional stuff. As I recall apt is doing it similarly.
My question is: if the update process is sequential, why packages on Discover list get downloaded simultaneously?

Many simultaneous process are in fact slower then when done one by one, at least it's often true to operation on files so I get the same feeling when everything is downloaded at once. Maybe it's just psychological effect but at the moment Discover creates very unease and confusing feeling during update.

And there is a matter of not asking for root credentials... Has someone filed a bug for it? I cannot trust Discover without it and it feels like exploit...
Comment 7 Aleix Pol 2018-07-25 12:12:58 UTC
Git commit 42083fa8ac72d88f8f4f2cc64b7e272347f9f8eb by Aleix Pol.
Committed on 25/07/2018 at 12:11.
Pushed by apol into branch 'master'.

Sort update items by completion

Summary:
Sort update items by completion.

Test Plan: Tested locally with dummy and packagekit@alpm (because I already had the rest up to date, needs more testing)

Reviewers: ngraham

Reviewed By: ngraham

Subscribers: plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D14250

M  +4    -1    discover/qml/UpdatesPage.qml
M  +7    -3    libdiscover/UpdateModel/UpdateItem.h
M  +12   -7    libdiscover/UpdateModel/UpdateModel.cpp
M  +2    -0    libdiscover/UpdateModel/UpdateModel.h

https://commits.kde.org/discover/42083fa8ac72d88f8f4f2cc64b7e272347f9f8eb