GNOME Bugzilla – Bug 557122
Default sorting is backwards
Last modified: 2012-01-08 23:19:43 UTC
The first time you click on any column in System Monitor, it sorts smallest-number-first. You have to click a second time to reverse it, and get biggest-number-first. In many places (e.g., sorting by ID number), sorting in ascending numerical order makes sense. However, in the case of most System Monitor columns, decreasing order is far more useful. If you click on the "% CPU" header, it's a good bet you want to see the processes with the highest CPU usage, not those with 0% CPU. If you click on "Writable Memory", you probably want to see those with the most writable memory, not a screenful of "N/A". For those columns which measure a (essentially) continuous value which users might reasonably want to keep tabs on (%CPU, memory, time), the initial sort should be greatest-to-least. For the ones which have a discrete value (ID, nice) or string (name, command line), it should remain in lowest-to-highest order.
I can confirm this is a usability problem. Bug 478794 is partially a dup of this one (and the other non-dup part of it is now fixed).
That wasn't clear, I meant to type "I can confirm that this bug still exists in 2.28, and it presents a usability problem."
*** Bug 478794 has been marked as a duplicate of this bug. ***
Created attachment 204819 [details] [review] Proposed patch The attached patch adds a custom sort method for the following columns: MEMXSERVER, VMSIZE, MEMRES, MEMSHARED, MEM, MEMWRITABLE, CPU, CPU_TIME, START_TIME. The custom sort method sorts these columns descending first to have the most consuming/last started apps on top. As a side-effect this patch also fixes bug 507108, as new processes don't ruin the sorting, not even temporarily, so the list remains sorted by the selected column. It should also fix bug 622403, as the columns are sorted based on their raw numerical values (bytes for memory sizes) thus are not influenced by the unit used.
Review of attachment 204819 [details] [review]: ::: src/util.cpp @@ -520,2 +520,3 @@ } + gint number_compare_func(GtkTreeModel* model, GtkTreeIter* first, Seems the code retrieving the size is duplicated, Please break that out into a static function. @@ +558,3 @@ + g_assert_not_reached(); + } + guint64 diff = size2 - size1; Subtraction operation being stored in an unsigned variable? Probably not your intention.
Created attachment 204844 [details] [review] Proposed patch v2 Duplicated code factored out in static method, and also changed the compare func to avoid calculating the difference between the two values, as it might overflow (result must be gint, and we are substracting guint64 values).
This patch has been applied in commit b439f813ceaf6ce6e82cd490c734c67aeb1f2028 and should resolve this bug.