Chris Wilson wrote:
Hi all,
Thought I'd get some views on this before digging around in the sourcecode.
When using Ethereal I've often wanted a "crop" feature - that would discard all the packets not matched by a particular filter, so that subsequent filtering is much quicker.
This would be a valuable feature, I've often wanted something like that
myself :-)
A little button next to "Clear" and "Apply" on the GUI mainscreen would be perfect.
Yes, it would fit best to the "filter toolbar" as I've started calling
it yesterday. Additionally, we might want to have a menuitem e.g. under
"File", but if we have the main functionality, that's easy to add.
I realise that this saving/reloading is probably going to be neccessary since all the packets will need to be refiltered once the unmatched packets are discarded.
So... do people think this sounds sensible:
A "Crop" button next to "Clear" and "Apply" on the mainscreen.
I'm not sure about the word crop itself. I currently searching for a
better one, maybe "trim". As I'm not a "native english speaker", there
might be better words for this I just don't see.
The button would save the displayed packets to a temporary file,
There are two possible reactions to the button press:
a.) always saving the currently displayed packets (hardwired, without
any dialog box), making things work with less clicks
b.) showing up a dialog box with the range frame (just like the "Save
As" dialog), let the user choose the packets to be saved, making things
more flexible
I currently don't have an opinion, if a.) or b.) would be better.
load the temporary file but still leave ethereal thinking it's editing the original file (so that "Save" overwrites the original file).
IMHO it would be better to display the new file as a temporary file (not
as a "faked saved file"), as thats what it is. In such cases I tend to
keep the original file, when saving a trimmed file, just in case I
missed something out and need other packets of this file later.
One thing left to think about: what should be done, if the current file
*is* a temporary file (recently captured)? As Ethereal can only handle
one file at a time, the original file would be gone, when the trimmed
file is made.
Hopefully I should be able to implement this without changing too much of the file loading internals.
Let me know your thoughts...
Cheers,
Chris