Bug 3190

It's not the status widget that is buggy, but the whole cascading relationship
of GuiProc -> GuiTask. As we know when we add a cascading observer to a GuiProc,
it is just an illusion. All those observers are really tasks observers. 

Until recently there was no formal relationship between a GuiProc and a GuiTask!
I fixed that several weeks ago when GuiTasks were added. The next problem is to
append the actual observer on the GuiTasks involved, when a cascading observer
is applied to the a GuiProc.

The second issues is that GenericActions{Points} seems broken. When I add say a
Syscall observer to Foo and Bar and add a generic action for both, the execute()
method does not have a Task parameter in the generic action. When a syscall
"fires" on Bar, for some reason, the action point on Foo is being called too
even though no syscall happened in Task Foo.

I fixed this is StatusWidget by changing TimelineAction from a GenericAction to
a TaskActionPoint, and filtering on the PID in the execute function. This
requires per instance filtering as well, which is clumsy.  There is still a lot
of work to be done in both areas.

Changelog entries reflecting what I have changed:

	2006-09-08  Phil Muldoon  <pmuldoon@redhat.com>
	
	* StatusWidget.java (TimelineAction.createEvent): Only add
	one glyph per observer type.
	(addObserverActionPoint): Changed clonedTaskActionPoint to
	cloningTaskActionPoint.
	(addObserverActionPoint): Changed forkingTaskActionPoint to
	forkedTaskActionPoint.

	2006-09-08  Phil Muldoon  <pmuldoon@redhat.com>
	
	* StatusWidget.java (addObserverActionPoint): New.
	(initEventViewer): Don't use generic action points (broken).
	(TimelineAction): Rebase on TaskActionPoint, not Generic.
	(TimelineAction.execute): Filter on passed task.

2006-09-07  Phil Muldoon  <pmuldoon@redhat.com>
	
	* observers/TaskSyscallObserver.java (runEnterActions): Remove double action call
	(runExitActions): Ditto.
	
	* StatusWidget.java (newTrace): Rename variable from trace1 to
	newTrace.
	(StatusWidget): Rename trace0 to initialTrace
	(buildEventViewer): New.
	(StatusWidget): Refactor viewer init to buildEventViewer.
	(initThreads): Rename thread linked list to threadList.
	(initLogTextView): Rename to initEventViewer.

I changed it so that TaskObserverRoot notifies the concerned GuiTask
whenever and observer is added to it. As a result the GuiTask is aware
of observers added though Cascading Observer or those added directly to
the task.

A still open issue is when should the proc be told that an observer (Cascading
observer) has been added to it ? What does removing a Cascading Observer mean ?

2006-09-10    <swagiaal@redhat.com>

	* observers/TaskObserverRoot.java: Added handling for addedTo and 
	removedFrom, which just forward the call to the GuiTask (part of fix
	for bz 3190).
	* observers/ObserverRoot.java: Removed onAdded and onRemoved runnables
	and all references.
	* observers/AttachedContinueObserver.java: Removed
	* observers/AttachedResumeObserver.java: Removed
	* observers/AttachedStopObserver.java: Removed
	* observers/DetachedContinueObserver.java: Removed
	* GuiTask.java: Removed observer.onAdded/onRemoved Runnables. This
	is now done by TaskObserverRoot.
	Added functions observerRemoved, observerAdded.
	* GuiProc.java: Removed observer.onAdded/onRemoved Runnables. This
	is now done by TaskObserverRoot.
	* EventLogger.java: Removed references to AttachedContinueObserver
	AttachedResumeObserver, AttachedStopObserver, 
	DetachedContinueObserver.

In continuing this fix it was found that DebugProcess when loaded from disk was
in fact creating a reference to the existing base observers instead of cloning
its own. This meant that one observer was recycled among all Tasks and was
causing part of the problem in StatusWidget. This also required a reference fix
the druid:

2006-09-12  Phil Muldoon  <pmuldoon@localhost.localdomain>
	
	* druid/CreateFryskSessionDruid.java (getProcessObserverControls): Use
	setCheckedbyName, instead of setChecked().
	* sessions/DebugProcess.java (load): Create a copy of the observer
	and do not add a reference to the base observer.

Also, as a leftover from the time when the eventviewer only had one trace (one
per process, on per thread), the markerId was only tracking the most recent
marker added. Fixed this by building a hashmap of observer type, and add the
traceID as the lookup value:

	2006-09-12  Phil Muldoon  <pmuldoon@redhat.com>
	
	* StatusWidget.java (TimeLine): Build a Hashmap of marker's to
	x-ref on actual observer execution.

These two fixes, along with the others, now enable multiple event tracking and
plotting per thread in the eventviewer.