
I'm currently contemplating doing the following drastic changes:

      Move to a toolkit independent architecture

      Use opStore for object persistence

      Split data gathering and action processing from visualization program
      so the viewer does not need to be setuid root.

      Adopt Plugable visualization modules and data driven graphics.


The current architecture is showing it's age and it was never really intended
to be what it has become. It's hampering forward progress and limiting the
functionality. The name may also change to better reflect it's purpose.
So time permiting, a rewrite is on the cards.

If things do not work out that way then I may do the following. Many
of these ideas will be adopted anyhow.

Todo 1.3 
========


RH 5.1 RH 6.1 RH 6.2 BSD Solaris8 Slackware 7.1 Caldera System V distributions


test for existence of external progs and give error message if they don't exist?

Todo - UnixWare, Solaris

    	Construct UnixWare/Solaras Packages
    	Regression Test on UnixWare 2.01

	Drop resize, trace and turn off setuid - then install to /usr/local ?

	Note: When not setuid lose the ability to signal descendants that are a
	different user id.

	Later:
		Use priocntrl to adjust process priority


	Check for real time priority values > 100 on Solaris 7

	Need to not write in current directory during install as it causes problems
	when su - root and on NFS.

	Mem leak? - Could be updating labels, fetching of data, updating distinguished
	Seg faulting after long run times, perhaps related to above.


Todo - All


----> Need to use the following so we don't put orphaned process group leaders
      under the gnome-session when they belong hanging off init. Do these
      occur naturally? If not then the current mechanism would be more
      efficient without the following test.... So we leave it out for now.

	( .xsession-errors  in File/Dir list ||
		Environmental variable Display is set )
	
	Add delay for main window resizing

	When turning window auto size on force a resize, so window gets redrawn.

	Allow security controls to be set from a file in the
	treeps lib dir(writable only by root). For now a system
	wide toggle if files exists, later allow lists of users
	to provide greater tunability.  -> opStore

	Use opStore for resource settings

        Push process "commands/actions" out into seperate "process control panels"
        that use xr3 based panels. Construct one per process.
        Put signals in option menus, have kill, signal, renice, trace as std.
        Write script to generate the files, the script will determine the
        doc files to use and add appropriate buttons to launch viewer.
        If no file exists use a std control panel. Search default location and
        allow users to create own panels in ~HOME/.opStore/components/ProcessControlPanels/...

	    konqueror  man:bash
	    konqueror  info:/bison
	    konqueror file:/usr/share/doc/HTML/default/kword/index.html

	    build list of files in
	    /usr/share/doc/HTML/default/	-> use konqueror

	    Netscape: can do
 	        gunzip -c /usr/share/man/man1/man2html.1.gz | man2html > hhh 
	        but links only work if apache running.

	    List of dirs in :

	    /usr/share/doc/  strip off version number, Browse doc dir - 
		open browser on dir.
	    Should also try to map other programs from the "dir" package name
	    Perhaps create a docmap or associated file map
	    Some kind of way to make window smaller yet have access to all of
	    the toolbar? Left/Right Scroll buttons?

	32/64 HiColor icon set 

	Remove or rename old /usr/local/bin executable during install.

	Allow /proc to be defined at run time, as /proc can
	really be mounted anywhere.  -> data gathering sub processes

	Add resources to show how to add scroll bars for user/group dialog
	also for color map

	Use priocntrl to adjust process priority

	Sometimes it's nice to be able to view a variable in all processes
	of a subtree, could support this by a right click on the details
	dialog label. Then mark field with a *, also new processes in that
	subtree should inherit the parents "display" list. The most common
	usageof this would be to watch the time.  Todo For Release 1.3
	Object oriented class hierarchy for per process actions,
	settings. Branch actions.

	Install kit for KDE, 
		Session management
		Internationalization

	Process classification with methods  -> opStore

	QT front end, KDE Integration?

	Fix - Setting resource to No menu causes many buttons to break!!!

	Ensure startup menu and toolbar buttons are in sync and set from
	resources if specified. - Replace with preferences

	Update color range average code, i.e needs to be updated and tested,
	but it's no longer used by default.

	allow display of tty/pty name  i.e   0,1,A,B or p0 q1 ...

	Create dynamic colors for users/groups without one?

	Simple, safe configurable user action menu items -> opStore

	Somehow show if swapped out? Already done -> color is black
	Could be better, perhaps a glyph.

	Better Handling of out of memory conditions

	Flash process box when it's had activity.

	New signal menus for UnixWare - replace with external methods
	Core dump on Solaris when not setuid
	Create resources for Solaris/UnixWare?

	BSD support

	PCP support via plug in modules

Todo For Release 1.4
====================

	Generic mechanism to drill down/extract, with platform
	specific libraries. i.e on Linux drill down of fd's and
	allow filename/path to be pulled to tree display.

	GTK front end, GNOME Integration

Todo For Release 1.5
====================

	Table View, other colapsable subpanels(log panel)

------------------------- Newer Ideas ------------------------

Have a log mode that feeds a stream of entries via a pipe to
a triggerProcess. This process then determines if an action
needs to be performed and spawns it if nesc. Internal actions
could be returned on the pipe. 

Specialized data gathering engines, opened via a pipe to gather
specific host dependent data. Could have these be pollable
by writing a request info packet, perhaps even specifying
what info to return. Thus could create specialists to gather
thread info, open fd info, ... These specialists could also
be used by the other monitor programs. If carefully crafted
these could also be spawned by inetd or infoNetd with a
socket connection. In essence specialized data gathering agents.
Should also have the ability to query for filed labels, field
tooltip string, field help... So develop a common protocol,
kinda like the SNMP agent/manager model, except make the MIB
queriable from the client.

Radial Pulse Graphs, shown as circular areas. Activty shows as
a circle, most recent is closest to center. Show amount of
activity by making circle thicker. As time passes the "activity
impulse" moves logarthmicly(sp?) outwards towards the edge of the area.
Fade impulse over time, make size of area a function of overall
usage. Use different colors for different kinds of activity,
i.e. green=cpu, red=mem, blue=io (perhaps use more muted colors).
Be able to turn these on/off and also only display for recent
activity then for a number of long tics(Rain Drop effect).
Could draw these on treewidgets window, and perhaps even in node
widget. Would be nice to use alpha blending. Really cool would be to
allow the waves to interact a little( like ripples in a pond ).

Perhaps allow area size to be based on resident set size but waves
are cpu impulses.

Along the same lines, alow process nodes to fade with lack of activity,
this could literally fade the colors and then eventually hide them or
outline them.

Allow a delta only mode, program only shows processes that
have values changing, keep them arround for a while
then shrink them.

Allow preset display lists per node

capture/replay

Really large trees don't draw properly. Looks like a
variable type overflow problem, perhaps a signed 16 bit value.
Develop some kind of large tree management strategy.


------------------------  Older ideas  -------------------------

In no specific order:


Linux 	Add more linux values to the displayable output. Perhaps
	drilling down into mmaps, fd's, ...


Per Process Actions:

	Define internal actions that the program can perform directly
	on processes, i.e. signal, play sound, ...

	Allow program detected triggers to spawn action:

		i.e program starts -> play sound
		    program waiting on disk io > 1 min -> stop net service

	Allow program specific user driven actions to be associated
	with each process. Develop classes and allow inheritance of
	classes. i.e.

		GNU class processes can have info run on them so
		a menu item called "info" is added to right click
		action menu.


	Allow association of normal/mini icons per process, then
	optionally show these in the tree. Use in detail dialog popup title.

	Perhaps add per-process data gathering controls and display
	controls as well. i.e.

		Never gather data on process mingetty, cause it's
		not used.

		Or always display time usage of httpd, cause 
		your running a web server and you always want to
		see that value.

	This info could be modeled on fvwm2 wmconfig mechanism. i.e
	each process has a file to describe these values. This could
	be extended to allow derived classes.


Finish Linting code (>75% complete)

LWP's

	Hide the actual structure of the process info structure and
	provide compile time dependent access macros. (Mostly done)
	Long term - encasulate this in a "object" and use access methods,
	perhaps even run time switching to support accessing different
	systems from one executable. Or simply make it data driven from

			type, name, ptr, format
	
	Could also move data gathering code to a run time library.
	(Started this by having seperate lib for data gathering, needs
	 to be more dynamic though).

	This might make graphic representation more difficult.

	Show Light Weight Processes

		Perhaps as different shape  Oval, rounded box, different
		font(smaller)

		Or inside the process box(Kinda implies it's a thread, which 
		it's not)

		stack of ovals(dynamically cycle through stack as threads
		activate?)


Resources

	More resource files, with better examples ...

	Migrate towards run time editable preferences


Multi-processor Machines, I need one of these to test on

	Color code by processor

	On multi-processor system could show trees for each processor and or
	an activity graph for each processor

	On these systems dynamically add processor fields to detail display,
	display list  ...

	Perhaps use connection color to indicate processor(Could also use
	connection color to indicate process group, session ...)


Multiple Machines

	Add a seperate gather process and use IPC to transfer info(i.e. RMON)

	Use MIB's???

	Provide graphical front end to select which machine

X Protocol messages - i.e. closing the window via window manager

		Details, Help, Alert, Timer dialog, Display list,

Persistant Objects

	Generalize color bars, help dialogs, icons, button bars ... to
	persistant objects which are retrieved via a common set of
	routines. These routines could then use a OBJECT_PATH variable
	to determin where to find the objects. i.e.

		Users_dir/tps_obj:Group_dir/tps_obj:Sys_dir/tps_obj

	Perhaps allow for remote system spec, object type URL

	Hmm beginning to sound like Java!!!
Help
	- Help for color bar,

	- Hierarchical help for help menu

	- Help text with hypertext links.

	- Provide an external help database(perhaps for multiple languages)
	  put this in a hierarchical directory structure. Bind into executable
	  simple english text by default.

	- migrate to HTML as KDE does

	- multi language support

Color bar

	- Make it a popup?

+ statistical color coding

	    Range selection for users/groups, only works when in count mode

	    Colors don't change when tree nodes updating on short tic

	    Should only update color map when changes.

	    Color map doesn't show multiple users/groups with same id.

		Would be nice to allow, either all, active or displayed
		user/group's. 

	Use better color's for examples

	Define color maps for various screen color depths, put these in a
	hierarchical directory structure and allow these to be bound at
	and during run time. Provide menu selection of these. Also provide
	color schemes and allow user to select/modify/save color schemes.
	Use X resources to define a default color scheme in case of absense
	of color map database.

+ Event->Actions

	+ menu toggles track button and key event changes

	Would be better to provide a more generic scheme, perhaps have menu
	and or button callback's invoke the Action procedure with the label,
	register translations with menu labels. The string's shouldn't be so 
	hard coded into the program!!!

	Should provide all menu/button settings from resource file(slowwww)

Button Work

	User control over which buttons shown
		from button bar config

	Perhaps if not enough space to show all buttons, display scroll left
	right arrows to pan over button space.

	Button bar as a either a package or as a widget

- Show/no show sched, init ?

- Controlling terminal hierarchy

      Process Groups

           session 1

           session n

-   Reflect above hierarchy by lightly box'ing the sessions, processes group,
    controlling terminal.

-   Visually distinquish the controlling terminal process, group and session
    leader's.  

-   Show foreground processes in the foreground and background processes in
    the background(psuedo 3d, real 3d? and/or VR?)

-   Allow  user to add a one line comment bar at bottom of main window, on
    cursor entry into a node, display process info.

-   Support all ps arg's, including list of process's ...

-	Perhaps a table view for old die hard's - easier to start top, ...

-   More graphics to represent various state's value's ...

-   pixmaps for user's, groups in user_group tree.


- Widget work

	- Connection color, style, thickness ... 
		
		Again have a default gc and if in default gc, use array's
		of lines. Otherwise have a list of linesegments and gc's.

