["Ronnie Sahlberg" <ronnie_sahlberg@xxxxxxxxxxxxxx>]

----- Original Message ----- 
From: "Blue Boar"
Sent: Saturday, November 29, 2003 7:14 AM
Subject: Re: [Ethereal-dev] Redesign of the WHOLE Ethereal main menu


> Ulf Lamping wrote:
> > I would need a concept, before implementing anything of this.
>
> Meaning a mock-up screenshot, or some code showing what I mean, or what?

A few mockup screenshots would be very good, so one can see how
good/horrible it would look before it is implemented.

>
> > Someone (I
> > think Guy Harris) has suggested, to optionally show only the number of
> > frames for performance reasons, so there might be other ideas about this
> > topic out there. BTW: Why do you think, this dialog shouldn't pop up?

Some people use ethereal to capture at high speed even with ethereal
(eventhough tethereal should be used)
and performance is an issue.
GUI candy that is continously updated during captures ARE making ethereal
slower and lowers the bandwidth treshold
where ethereal no longer can capture packets without dropping most of them.
Not everyone captures on slow 10baseT links with little traffic.

To much gui candy during capturing will make ethereal completely useless for
capturing for everyone except those capturing on slow 10baseT or ppp links.

Performance is very important.  I would say that from now on, no new major
features should go in without a
performance analysis and how and what perfromance it will affect.


>
> It's an annoyance, it doesn't keep me from using Ethereal to do what I
> want.  Basically, I don't like having to keep track of two windows.  I use
> Ethereal primarily in MS Windows, and I alt-tab to switch between windows
> frequently.  I can't tell them apart when doing that.  Also, it seems a
bit
> strange to start the capture in one place, and stop it in another.  I also
> have next to no use for the summary statistics, but I imagine others
might.
>   I guess if we wanted to please all of the people all of the time, we
> could make any of the windows tear-off/parkable.  I have no idea if the
> libraries used can support that.  Having them as a 4th pane that I could
> resize (out of existance) would be just fine. :)

Yucc.  Please not a fourth pane.  We loose too much gui space in the main
window as it is already.
Please do a screenshot mockup so we can see how much space it will steal
from ethereal.

>
> >
> >> I'd also prefer that the start/stop functions just be toolbar buttons,
> >> now that a toolbar exists.
> >
> > It isn't a good idea to put functionality only in the toolbar/context
> > menu/..., as someone could disable the toolbar and won't even see the
> > possibility for using this.
>
> I could have been more clear.... I don't neccessarily mean "just" on the
> toolbar (and nowhere else).  I mean on the toolbar, and a Capture->Stop to
> go with Capture->Start.  Making the "stop" button on the pop-up window
> unneccesary.

a capture->stop item sounds useful.
But the stop button should still remain in the capture dialog.
During the capture the main window is "unresponsive" and will not react to
any user input.

This is for performance since having the gui completely responsive at this
point will make ethereal slower.
When etehreal slows down, the bandwidth treshold where we can capture
without packetloss is decreased.

Please test using "update in realtime" enabled and disabled when doing
captures.
With this option as enabled,  ethereal is close to useless for capturing
data since it will loose almost all packets
except on the very slowest and most idle links used.

While this performance problem is bound to happen anyway sooner or later and
really forces people to use tethereal instead for real
captures,  it is still good if we can use ethereal to create medium
sized/medium throughput captures.

Many people use Ethereal for high throughput high speed links.
For capturing medium to fully saturated GbE links  ethereal is useless and
tethereal must be used.
For capturing medum utilized 100baseT links Ethereal CAN be used if "update
in realtime" is not enabled.
For capturing low utilized 100baseT links or 10baseT links ethereal with
"update in realtime" can be used.

Myself, I never capture on non GbE links since I dont have access or use
anything that is not GbE or faster.
I wouldnt be affected at all since ethereal is already to slow to be useful
to capture on those links.
However, there are people capturing on slower 100baseT links and if we make
it slower they will
no longer be able to capture using ethereal.

>
> >> would also be nice if the auto-scrolling was something I could click
> >> on and off while capture, rather than having to pick it once when I
> >> start.
> > I would agree, but I have lot's of other things to do, so don't expect
> > anything to be happen on this topics in the near future...
>
> Great, so I have agreement on that feature in principle? :)
>
> Seems like it is fairly acceptable for any coder here to supply a patch
for
> review?  Maybe it's time for me to take a look at the Ethereal source.
> I'll have some time in a week or two.
>
> BB
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev