GNOME Bugzilla – Bug 92724
Simple (unthreaded) process listing view doesn't stay at top of list
Last modified: 2013-05-05 23:12:05 UTC
System Monitor 2.0.2 (deb: gnome-system-monitor 2.0.2-1) Steps to reproduce: 1. Uncheck Edit > Preferences > Process Listing > Show...Dependencies 2. Check Edit > Preferences > Process Fields > ID 3. Sort Process listing by ID column, descending 4. Scroll Process listing view to top 5. Start a new process Expected results: New process appears at top of Process listing view Actual results: New process listing appears above the Process listing view, need to scroll up to bring it into view. Can be reproduced with at least the 'Memory' field as well, but not '% CPU'.
So if the scrollbar is at the "top" or "bottom" and a new process is added to the list, the "top" or "bottom" position should be maintained. Adding bugsquad keyword, leaving severity as minor (I can imagine how this might cause irritation)
Does this still happen? Probably a bug in gtk that has been fixed.
Yes, this does still happen. System Monitor 2.4.0 (deb 2.4.0-1) Updated steps to reproduce: 1. Uncheck View > Process Dependencies 2. Check Edit > Preferences > Process Listing > Process Fields > ID 3. Sort Process listing by ID column, descending 4. Scroll Process listing view to top 5. Start a new process
Reopening then. Does it occur in 2.6.x too btw?
yes it does, System Monitor 2.6.0 (deb 2.6.0-5)
*** Bug 164401 has been marked as a duplicate of this bug. ***
[Adding missing "QA Contact" entry so system monitor bug report changes can still be watched via the "Users to watch" list on https://bugzilla.gnome.org/userprefs.cgi?tab=email when the assignee is changed to an individual.]
Can anyone confirm on 3.4.1? I have tried, and processes do appear on top of the list, I don't have to scroll up, so it might have been fixed sometime in the last 7 years :).
3.4.1 seems to behave the same as originally reported when sorted by id desc
Confirming this, with the note that with Dependencies (process tree) turned on, this works correctly, but when showing the plain list, the list is not scrolled to the top/bottom.
*** Bug 698879 has been marked as a duplicate of this bug. ***
Bug 698879 was just marked as a duplicate of this one. I agree it's basically a duplicate, though up until now this bug has been about what happens when a new process is created and you're already scrolled to the top or bottom, and bug 698879 was about what happens when you're somewhere else, i.e. in the middle. Most generally, I think the idea here is that the scroll position should be maintained as follows: - if you were at the top or bottom and a new process arrives, you should be at the top or bottom of the updated list afterward - if you were not at the top or bottom and a new process arrives outside the current view, the view should not visibly change - if you were not at the top or bottom and a new process arrives inside the current view, it should be inserted, and the process at the top of the view should not change
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.