Bug 127728 - Wish: display more details for a process (like sysinternals/process explorer has)
Summary: Wish: display more details for a process (like sysinternals/process explorer ...
Status: CONFIRMED
Alias: None
Product: ksysguard
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR wishlist with 100 votes (vote)
Target Milestone: ---
Assignee: KSysGuard Developers
URL:
Keywords:
: 47053 150350 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-05-20 22:06 UTC by Diederik van der Boor
Modified: 2010-02-17 13:21 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Diederik van der Boor 2006-05-20 22:08:03 UTC
Version:           1.2.0 (using KDE 3.5.2 Level "a" , SUSE 10.0 UNSUPPORTED)
Compiler:          Target: i586-suse-linux
OS:                Linux (i686) release 2.6.13-15.8-default

Recently I've tried "process explorer" for Windows. This tool can be found at http://www.sysinternals.com/Utilities/ProcessExplorer.html

In my experience, the UI is very clean, while the tool provides _a lot_ for detailed information about a process:
- the tcp/ip connections the process has open.
- the libraries it has loaded
- the environment variables the process has.
- the security context of the process (think selinux)
- the strings the process contains (both image and memory)
- the threads it has open, including their starting point.
- the cpu and memory usage per process.

So my which (for KDE4) is: could some of these features be included in the KDE ProcessList tool too? Most of the information is already available in /proc/. "Process Explorer" could be used as inspiration.

Thanks in avice.
Comment 1 Greg Martyn 2007-09-30 19:07:13 UTC
*** Bug 150350 has been marked as a duplicate of this bug. ***
Comment 2 jos poortvliet 2007-09-30 19:14:41 UTC
Would love to see some of these features... sorry for the duplicate bug :D
Comment 3 John Tapsell 2007-11-12 13:06:19 UTC
Url for process explorer has changed to: 

http://www.microsoft.com/technet/sysinternals/utilities/processexplorer.mspx
Comment 4 Romain 2009-05-20 11:10:39 UTC
+1. A nice feature of Process Explorer is that when displaying the detailed info about a process and the process dies (or terminates) then most of the information is still available. 

In particular (and what would interest me most) is that the graph of memory usage is still available. This way I can run a medium-length process, call up a detailed info window and just wait. Even if the process terminates, I still have a chart of memory usage and I can check the general trend.
Comment 5 John Tapsell 2009-05-20 11:24:10 UTC
I keep thinking about this wish.  It would be good to be able to launch a process in this way, so that a very short lived processes can be monitored.

On the implementation side, I think the best way is to have a seperate application that is entirely coded in javascript or something.  I want something that users can easily modify because otherwise I'll get a bajillion new wish requests for information that people want to show.
Comment 6 Romain 2009-05-20 11:50:08 UTC
Hey, the monitoring of short processes is a funny idea (i.e. a good one) !

About the implementation, I think that some ideas can be stolen from plasma: base classes in C++ with bindings to higher-level languages (JavaScript, Python, etc).

Those base classes could be split in data sources (memory usage, file accessed), and data monitors (graphs, lists). Afterwards, it's a build-your-own data source or monitor, or use the default ones. Plug them all together, add a few predefined configurations, and you're good to go. Perhaps plasma already has those base classes available ?
Comment 7 Diederik van der Boor 2009-05-21 00:03:47 UTC
> On the implementation side, I think the best way is to have
> a seperate application that is entirely coded in javascript or something.
...
> Those base classes could be split in data sources (memory usage, file
accessed), and data monitors (graphs, lists). Afterwards, it's a build-your-own
data source or monitor, or use the default ones.

err... that's really not what I meant. By bug report is about adding a "detail" dialog to ksysguard, with has tabs for various information about a process, which can only be accessed from /proc right now. Please take a look at process explorer, you'll understand what I mean. :)
Comment 8 Romain 2009-05-21 11:47:25 UTC
(In reply to comment #7)
> err... that's really not what I meant. (...). Please take a look at process
> explorer, you'll understand what I mean. :)

I use process explorer daily and it's indeed a *great* application. But if I understood John's comment correctly, he is wary that he'll get such a large number of requests for some features to display that he wants to make it easy for developers to create (and distribute ?) their own apps.

On the UI side, the new "detailed" monitor could be launched from ksysguard. Or a default dialog could easily be implemented in terms of the base bricks inside ksysguard itself. It's all about having a flexible design from the start.

But then again, perhaps I'm confused. :)
Comment 9 John Tapsell 2009-05-21 12:47:35 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > err... that's really not what I meant. (...). Please take a look at process
> > explorer, you'll understand what I mean. :)
> 
> I use process explorer daily and it's indeed a *great* application. But if I
> understood John's comment correctly, he is wary that he'll get such a large
> number of requests for some features to display that he wants to make it easy
> for developers to create (and distribute ?) their own apps.
> 
> On the UI side, the new "detailed" monitor could be launched from ksysguard. Or
> a default dialog could easily be implemented in terms of the base bricks inside
> ksysguard itself. It's all about having a flexible design from the start.

That's exactly what I meant :-)

The process list part is actually always in memory when running KDE, so that it can load when the system is under heavy strain (since that's when you most want to kill a process).  So the process list part itself needs to use the minimum amount of memory.

So what I want is a seperate process that is launched when you want to view the details of a process.

Also on the flexibility side, ideally I want to spend a weekend writing a simple application that is just a single browser widget and a javascript engine with a couple of a functions to read files from /proc.  Then rely on other people to write the complex html to display the huge amount of information available in /proc for a process. (which frankly I don't understand).  It would be great for someone to write a parser for the memory maps, for example, to show the memory usage of the apps, visually seeing how applications are sharing memory.
Comment 10 Diederik van der Boor 2009-05-21 18:51:45 UTC
John: I stand corrected :) Having a separate process definitely seams to make sense to me, and getting a rich view could give an interesting outcome too.
Comment 11 John Tapsell 2010-01-30 17:41:47 UTC
*** Bug 47053 has been marked as a duplicate of this bug. ***
Comment 12 Martin Koller 2010-02-17 12:03:50 UTC
*** This bug has been confirmed by popular vote. ***
Comment 13 John Tapsell 2010-02-17 13:21:06 UTC
The scripting support is improving rapidly for KDE 4.4.