
Treeps is not a KDE app, well at least not yet, it is in the process of
migrating that way. However, it can be integrated into the KDE 
desktop using the install_kde script. This will make it appear in the menus
and allow it to be placed on the desktop if you wish.

Why do this? Isn't there a ktop which has a tree view?

These are good questions, and I took some time to think this through,
and here are the reasons.


While ktop provides some of the same functionality, treeps provides
much more. For the casual user ktop may be fine, however for others
a more powerful combination might be to use qps and treeps.

I also have some longer term goals for treeps that fit well with the KDE
environment. Specifically I am planning on continuing to develop and
enhance the "data mining" metaphor. I want to be able to drill into a
process(in KDE a container of objects/components) and be able to extract
up attributes for display in the tree. Eventually I want to be able to
add dynamic visualization of these extracted variables as well as enable
their use in scripted event triggers. Why? Well to be able to visualize
the systems activities in a cohesive/coherent and natural way. Obviously
this will take some time to implement. I also want this tool to be
portable to all Unix environments, which still means dependence on
Motif. So while I want to adopt KDE, I don't want to drop Motif.

The next major release of treeps will objectify the processes, i.e. each process
will be classified. These classed processes will have a number of attributes
including:

	Actions - These will be used to generate a dynamic menu of actions
		  that can be performed on the process. e.g. a inetd will
		  have a reloadConfig() action i.e. a kill -1. GNU commands
		  with info files will have an info action, commands with
		  man pages will have a man action, kde apps will have
		  a KDE help menu item, ...

	Icons - used to display an icon if desired

	DefaultViewList - What values are displayed in the tree by default

	DefaultViewState - May be hidden by default

	KnownSignalsUsed - May be used to create a short list of relevant
			   signals


	PollRateHint - Can be used to tweak the polling of data


	and many more


To accomplish the GUI personality switching I plan on 

	Splitting the code into a gui part and a data processing part.

	Pushing the gui part into a run time linked library

	Creating Motif, GNOME, KDE run time libraries

	Pushing out detail viewers into seperate programs, i.e.
	
		An Open Fd Viewer

		Environment Viewer

		Memory Map Viewer

Each of the viewers can then be a much simpler program written in
Motif, KDE and/or GNOME. This will allow the code to be smaller,
more modular and easier to develop and maintain. There is also the issue
of differences between systems and versions in what details to display,
it becomes a lot easier to deal with the config issues if they are seperate
programs. Finally these smaller programs can be associated with the
directories/files in /proc for another way to browse process info via
a file manager.




