After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 698879 - process list does not maintain scroll position when processes are created/destroyed
process list does not maintain scroll position when processes are created/des...
Status: RESOLVED DUPLICATE of bug 92724
Product: system-monitor
Classification: Core
Component: process list
git master
Other Linux
: Normal normal
: ---
Assigned To: System-monitor maintainers
System-monitor maintainers
Depends on:
Blocks:
 
 
Reported: 2013-04-25 17:56 UTC by Adam Dingle
Modified: 2013-04-25 21:05 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Adam Dingle 2013-04-25 17:56:57 UTC
To see the problem:

1. Open the Processes tab in System Monitor.  Make sure that View->Dependencies is unchecked.  Click on the Process Name header to sort processes by name.
2. Scroll down part way through the process list.
3. In a terminal window, start a large build that will compile many files.

As the build creates and destroys processes, System Monitor will change the scroll position: it will jump forward periodically.  This is annoying when you're trying to read the process list.  It would be nicer if the scroll position stayed constant in this situation (of course, System Monitor should still insert and delete processes from the current viewport when applicable).

This is related to bug 611735 (memory map scrolls on each refresh).
Comment 1 Robert Roth 2013-04-25 20:59:46 UTC
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.

*** This bug has been marked as a duplicate of bug 92274 ***
Comment 2 Adam Dingle 2013-04-25 21:02:37 UTC
Surely that was an error, since 92274 is a GnuCash bug.  Want to try again?
Comment 3 Robert Roth 2013-04-25 21:05:02 UTC
Thanks for the heads-up, that was a typo :)

*** This bug has been marked as a duplicate of bug 92724 ***