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.
*** Bug 150350 has been marked as a duplicate of this bug. ***
Would love to see some of these features... sorry for the duplicate bug :D
Url for process explorer has changed to: http://www.microsoft.com/technet/sysinternals/utilities/processexplorer.mspx
+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.
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.
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 ?
> 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. :)
(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. :)
(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.
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.
*** Bug 47053 has been marked as a duplicate of this bug. ***
*** This bug has been confirmed by popular vote. ***
The scripting support is improving rapidly for KDE 4.4.