Re: Eventviewer refactors.

[Phil Muldoon <pmuldoon at redhat dot com>]

Thanks Nurdin for these viewpoints. They illustrate some great examples 
of lateral thinking in terms of presentation, and how we can change that 
presentation to the user. However, first we need to answer: what is the 
identified need for these work-flows, and justification? User?  Personal 
thoughts? Meeting of minds somewhere? We have to get our story straight 
on why we need these changes. Why do we need to get rid of the process 
view? Why do we need to mix thread and processes together? And so on. So 
without further ado, my comments:
> 1. Having an "all" processes view, so that users can see the
> interactions between different processes. Easiest method is to add an
> "all" selection to the process tree. (Assuming more than one process) I
> believe I did some work on this before. One minor issue is that I have
> no idea what to put for the PID column. Ideally I would leave it blank,
> but I don't think I can do that (it defaults to 0? Which would just be
> lying).
>   
I feel we might as well get rid of sessions entirely then, because it 
basically defeats that work-flow. What's the point of going through a 
session at all? To perhaps answer this question myself, I could see a 
toggle where you flipped between full process view and session targeted 
view. But I'm worried we have been spending a lot of time evolving 
sessions so that user can narrow down their focus on a directed UI, and 
now we are just blowing it open.

Question to answer:

1) Why do we need this?
2) What purpose will an all process view serve? Add things back into a 
session view?
3) If 2 is correct, do we save any changes? Are they session bound?
4) Given the whole process view, do you anticipate mixing in threads?
5) if 4) what additional value will mixing in thread serve over having 
them separate
6) in 4) how will we handle large thread producing programs?

If we can answer these questions, then I think this work-flow might work 
pretty well. However ...

> 2.0 Removing the proc/thread tree and just having the eventviewer and
> main log. This would look something like the attachment
> frysk-monitor-no-tree-view.png.
>
> This would be a large refactor as I would have to implement selecting
> traces in the eventviewer in order to add right-click (secondary-click
> for us left-handed people) menus to the traces  themselves rather than
> in the tree-views.
>   
I find the screen-shot non-intuitive, and confusing. I completely 
disagree with this. Arguments have been made that sessions should have 
PIDs because engineers are used to working with PIDS. In this scenario 
we remove PIDS and existing process names. How do we switch between 
processes? When the user is presented with this view, what are they 
supposed to do?

1) What would removing the process tree achieve?
2) The thread view will soon have more information that it does now. I'd 
say remove the thread view until then.

Perhaps to better answer my objections some further thoughts. Personally 
right now I think we should be spending our effort making the 
event-viewer better. Perhaps then we can address these questions. Things 
like:

1) Grid
2) Selecting traces
3) Orientation vertical/horizontal
4) Scalability and zoom during a user defined time period

I think then, we can answer these work-flow questions more clearly 
because then we have a clearer picture on how we want to display the 
data that is being presented. I think these refactor's are a bit 
premature, especially in light of the others we are looking at detailed 
below. There are already several thoughts in place, and I think we 
should answer these first.

Also it's been my practice to integrate choices in the UI. When I 
rewrote the Debug Single Process launcher, I had feedback that people 
wanted PIDs right aligned, that sorting was suspect, and column order 
was wrong.  I designed the next UI with those flaws in mind and came up 
with:

1) A separate column for PIDs
2) Columns you can drag and order as you like
3) Ascending and Descending sort on any column.

Ideally, in presentation, I'm moving toward giving the user a choice. 
Ultimately I think we should allow the user to hide the process 
tree-view, or hide the thread tree-view, and maximize the event-viewer. 
Or size them and place them as they wish.

The issues I am looking at right now.

1) Multiple sessions running at once (WindowManager rewrite)
2) Workflow disconnect between launch a session and monitor

With 2) Right now we dump the user in the monitor from the session with 
no hint as to what to do next? Where to go? What to click on? Where 
should we go?

Regards

Phil

> 2.1 Removing just the thread tree view, would look like
> frysk-monitor-proc-tree-view.png
>
>
> So now for a show of opinions:
>
> 1. "All" process in process tree view: Yes or No, If no is there a
> better way of showing the "big picture"?
>
> 2. Removing proc/thread view: Yes or No:
> 	If yes, replace with:
> 	A) Tabs
> 	B) Zooms
> 	If no, should we go with 2.1?
>
> And my opinions:
> 1. Yes
> 2. Yes, replace with tabs at first, then zooms.
>   
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------