Wireshark · Ethereal-dev: Re: [ethereal-dev] Graphs working

[Bibek Sahu <scorpio@xxxxxxxxx>]

On Tue, 12 Oct 1999, Gilbert Ramirez wrote:

> On Mon, Oct 04, 1999 at 11:11:49PM -0500, Bibek Sahu wrote:
> > 
> >         * Summaries are updated with every incoming packet.
> 
> I agree that we need graphs that are updated while the capture is
> being made, but we will also have graphs that don't lend themself
> to "real-time" (I use that word loosely) usage. I'm planning a graph
> showing a directed-graph of protocol connections, along with
> packet counts per protocol and per protocol-to-protocol stacking. This
> will graph will take time to build, so it won't be updated during
> a capture.

	/Summaries/ are updated with every packet, not graphs.  Still,
graphs are updated on a regular basis, and /forcing/ all graph types to
update with them is a bad idea.

	I've cleaned up the code a fair bit.  I'm planning to attack the
UI with glade this week sometime (though that may be pushed back to next
week if I get too busy...) and release an updated patch.  Among other
things, I have implemented "live" updates.

	I'll add some fields to the graph_info struct and support for them
in the updating functions so that new graphs can specify that they are not
to be updated in real time (see below).

> What do you feel is the best way to separate these two types of graphs?
> At the main-menu level? "Capture Graphs" might open up your window of
> summary items, and "Analysis Graphs" might open up a window showing
> the slower graphs.

	At the main-menu level, I'd like to have a "Graphs" dialog box
containing everything relevant to maintaining graph information.  This
will contain multiple tabs/panes/something (probably tabs) to separate the
related items.

	It is possible to have summaries active without having graphs tied
to them (and I've actually made use of this recently), so one tab was to
be "Summary Maintenance," wherein one could activate or deactivate various
summary items.  The last patch I sent activated things on graph-creation,
but provided no way to deactivate them, so this was necessary anyway.

	I had intended one other tab for "Graphs" in general -- select a
summary type, and click on either "Create Histogram" or "Create Pie Chart"
or etc., etc., etc.  I'll probably still have this, but it will probably
be "Capture Graphs" as you suggest.

	And instead of an "Analysis Graphs" menu item (or in addition to
it), I'll drop in a tab for "Analysis Graphs."  Since I don't know what to
do with this, I'll leave it empty in the next patch. ;-)

	Another thing I could do is have a per-graph timer.  That way, the
user could specify the frequency of updates for each graph, rather than
having all graphs updated at a certain time.  Doing it this way, I could
decide based on the power of my computer and the complexity of the graph
how often (if ever) to update a given graph during a live capture.  And
for a complex, analysis-type graph, I would probably say never (or may
make it once every 10 seconds sometime, to see how the Alpha handles it
;-).  The more I think about it, the more I feel that this will be the
cleaner approach.  What do you think?

	I haven't started any of this yet.  I want a solid foundation (the
stuff I had in my last patch) before attacking more "esoteric" items.
However, I'm getting Really Close to implementing them, so I would /love/
to get some constructive criticism at this point.  I'd like the end result
to be as good as can be, and I'd prefer not to have to rewrite the entire
thing to make it so. ;-)

	Incidentally, one of the other things I've done is create a
scrollable_pixmap widget.  Basically, you draw on a GdkPixmap, and it
takes care of keeping it drawn properly on the screen (and implements
scrolling for Really Big Graphs, like the wide ones I'm playing with).
Later, I'll put printing / save-to-file support in the generic graph code
(request from work), so you can save your directed protocol graphs and I
can save my histograms. ;-)

> --gilbert

- Bibek