Nurdin's plans for the eventviewer

[Nurdin Premji <npremji at redhat dot com>]

So I created a few bugzilla feature requests against myself on thursday
and here is where I plan on going with the eventviewer.

First: clean the clutter, which I keep forgetting to do.
Things to do here: Get rid of the buttons, I'm not a big button fan, so
I have plans to introduce functionality that will obsolete these
buttons. (Hold button, see Bug 3021)

Bug 3025: Vertical time EventViewer. So make the eventviewer time axis
on the vertical, that way the event log can go on the right side of it,
and the events in the text log can be linked up with the events in the
eventviewer. So what the event log needs to morph into is something
along the lines of the tree views on the left hand, where each element
can be selected, and maybe taken to the event in the eventviewer.

Bug 3023: Complex traces: What I mean by this is instead of having a
trace that has only one straight horizontal (or soon to be vertical)
line, it becomes a jagged line based on cpu usage, or memory usage, or
more important things based on user preference. Somehow, I haven't
really thought about what it should be based on, how to change between
them, etc. So that shouldn't really require anything from the rest of
the monitor, mostly an eventviewer feature. The way I plan to do this is
that each trace gets its own little area, (ex. ten pixels) and its % of
cpu/whatever usage is based on those 10 pixels. I think this would be
better explained with a screen shot, which I will draw up and post to
the list to see if people like.

Bug 3022: Complex scrollbar:  There is the idea of having the scrollbar
contain information about the eventviewer directly inside it. Sort of an
"overall" view of the eventviewer. I like Andrew Cagney's idea/concern
that the user should be able to see multiple processes interacting at
the same time, as that would be useful for debugging. However I don't
know how we can get a massive number of processes and threads shown in a
small-medium sized widget. My short answer is that we should assume a
limit of several threads/processes as I don't believe that the human
mind can keep track of so many processes. In terms of implementation, I
have no idea where to start. Maybe constantly take a bitmap of the
eventviewer? Or render directly into it. I dunno.

Bug 3021: Mouse-edge Scrolling: Dragging the mouse to the edges of the
eventviewer should be able to scroll the eventviewer in that direction.
A side effect of this can be that dragging the mouse all the way to the
right enables auto-updates (what the hold button deactives) and focusing
the eventviewer anywhere left of the right-most edge will deactivate
auto-updates (activate hold). This way I can get rid of the hold button.

As for the Center button, it really is just a zoom-out feature as much
as I can tell, so once I try to enable mouse wheel zooming I shouldn't
need to use that anymore, a simple push of the scroll all the way down
should zoom out all the way.