Ethereal-users: Re: [ethereal-users] Re: [ethereal-dev] static vs dynamic column width
> > > The other item which is related to this issue is the
> > > "Follow-the-Stream" changes. If this is going to put each of the actual
> > > application messages on an individual line rather than whatever-sized
> > > chunk of data TCP happened to blast out, then I won't be as worried
> > > about the full info string. Right now, you wouldn't see some commands,
> > > but if each application message gets a display line, then you'd only
> > > miss seeing some of the parameters rather than one or more entire
> > > messages. Could someone give me a few details on the follow-the-stream
> > > implementation?
>
> I'm not sure what this is referring to since I've not been following
> users-dev,
I'm not sure what it's referring to, either; I don't think the behavior
of "Follow TCP Stream" has changed - I think the only change is to the
timplementation, to make it work atop the new display-filtering
mechanism.
What "Follow TCP Stream" does is spit out the raw data in the TCP stream
(reassembled in order) to a file (no TCP or lower-level headers, just
the TCP payload) into a file, and pulls up that file in a text window;
this is more useful for text protocols such as FTP, SMTP, POP, HTTP,
etc. than for binary protocols such as SMB.
> but if you are planning a more Sniffer-like display with
> multiple Info lines per packet, with different levels of decode on each
> line, that would be useful. I do like being able to optionally see more
> detail in the packet listing with the Sniffer, without having to go to
> the full details display. That feature of the Sniffer is nice in that
> it is completely user configurable -- the user can specify which levels
> of the stack are to be decoded and displayed with each packet.
> Normally, I use a single-line display with the Sniffer, but it is
> sometimes helpful to see more.
I think that's been discussed as well, but I don't think anybody's
working on it at the moment.
> If you mean something else, perhaps about the connection, I'd like to
> hear more too.
>
> > > For the columns other than "Info", the default sizes are probably okay
> > > (meaning static width would be okay) during the capture, as they seem to
> > > have realistic values for the width.
> > >
> > > Regarding user's preference for column type/widths in a .preference
> > > file, perhaps we should just have a preference for static or dynamic
> > > sizes. Of course, you could do both, having a preference for static or
> > > dynamic for each column type, and even a preferred width.
>
> A few thoughts: The only resizing version I have seen is 0.6.3 -- and
> that had what were since described as bugs where the column widths
> shrank and grew alternately. I might not have reacted so strongly if a)
> columns never shrank, b) once the user adjusted a column width, the
> column would not be resized again, and perhaps c) column widths didn't
> change in response to packets not visible in the window. All these
> issues apply only during that -S session. Initial resizing was not a
> problem for me.
>
> I've thought it might be nice to save the current column widths as a
> preference setting. It's a minor convenience.
Unfortunately, there's no way to get the current column widths from GTK+
without "reaching around the back" and extracting them from the raw
toolkit data structures; arguably, this is a deficiency in GTK+.
