Ethereal-dev: RE: [Ethereal-dev] Saving all packets between the first and the l ast marked pac
| From: Ian Schorr
|
| My suggestion a while back was to provide a pop-up dialog
| that allowed
| the user to mark a range/set of packets. This range marking would be
| similar to what you suggested, i.e. allow "1-4,8,10-50", as well as
| options to "mark all" or "unmark all". In this case, the
| user would be
| able to flexibly and quickly control marking, and then use
| the existing
| "save marked" option to save this set of packets.
|
| I think this makes the most sense, and a "print marked
| packets" option
| could fairly easily be created, which would be a bit more
| modular (and
| intuitive, IMO). This would also be far simpler than some of
| the other
| suggestions.
Simple is a matter of taste :))) I think we already have all important bits
and pieces implemented for this, we only need to tie them together in a
smart way. For instance, if a dfilter is applied, a filtered (primed) tree
is constructed, so if you say 'apply dfilter to marked selection' you can
start from the filtered tree and look up only the marked ones.
But I agree with the fact that we should keep the GUI as simple as possible.
Letting an end-user choose between many options causes lots of confusion.
That was the reason I proposed to decouple the dfilter match from the other
selection criteria. By doing so, you eventually add more options than we
really needed, but we give the end-user the impression that a dfilter is
orthogonal to packet marking, hence you can avoid to put all permutations of
selection criteria into a radio button item.
| The "save "(or print)" between first and last packet" option
| is just bad
| UI design, again IMHO, and not flexible enough.
Maybe. But I know some Ethereal users capture huge amounts of packets, in
order to spot specific (sometimes periodic) errors which require the
end-user to process this data over and over, to follow a TCP stram and then
mark all filtered frames etc, to obtain a list of marked frames where you
*think* the problem occurs. Maybe there are erratic packets in between the
marked ones, which are relevant too. In this specific situation, the "XXX
between first and last marked packet" option really makes sense.
I however agree that there are lots of ways to describe what we want in such
a way that an end-user doesn't require the manual to perform what seem
obvious actions to us.
| One question - what other current or potential uses does
| packet marking allow?
|
| We'd also need to clean up the way marking affects coloring
| of packets
| in the packet list (well, we really do anyway).
That's a bug of the Middle Ages :) Everyone knows it but it's hard to find
the seolution for it. It'd be easily solved if we kept the protocol summary
in some set of list/tree data structures and use a limited set of UI
elements to render only the visible UI items (E.g., one summary line). If
the UI changes, one could live with the fact that the given UI element (or
even itsentire set) is repainted. This would not be true with the GtkCList
we're using today.
| Ian
|
| Biot Olivier wrote:
|
| >I partally agree. I'm in favor of decoupling how the
| end-user interacts with
| >the system and the way the system is implemented. Anyway, I
| think we will
| >move to a more powerful selection mechianism in a stepwise manner.
| >
| >The questions I have, are all related to how intuitive the
| UI is to a human.
| >For this reason and because it makes sense to me to decouple
| dfilter from
| >selection criteria (although the implementation does not allow full
| >separation of both).
| >
| >Additionally, If one wants to print/save only a selection of
| packets, why
| >wouldn't we let the user enter the ranges, just like it is already
| >implemented in various SW products in the "Print pages"
| widget? I think it'd
| >be much mode interesting if an end-user could specify ranges
| like "-20",
| >"25-40", "120-" or a combination of those:
| >
| >( ) Specify ranges: [ -20 35-37 45 78- ]
| >
| >Would then select only packets (first) to 20, 35 to 37, 45,
| 78 to (last).
| >And even then, it would still make sense to apply the
| dfilter on demand for
| >the entered selection.
