Guy Harris wrote:
The "Output to File" option has a "Browse:" button. That's the
convention used on Windows; I don't know what's used on various UNIX
GUIs.
Should we use that, rather than having the label for the file name
field itself being the browse button, in other places, e.g. in the
"Capture Options" dialog?
Should we do that for "Filter:" fields as well?
Currently I just don't know :-(
As for the UNIX GUIs:
KDE: this screenshot:
http://printing.kde.org/screenshots/pics/printdialog.png
for a KDE print dialog seems to show an iconic button for browsing,
although I don't see how to say "print to a file".
GNOME: I think there's a gnome-print dialog, although I don't know
whether it's an official part of GNOME yet, and I haven't found a
screenshot.
Mac OS X: I haven't seen a "print to file" option, although there is a
"Save as PDF" option.
That brings up another question:
what exactly does "output to file" mean?
It looks as if Mac OS X might be implying that printing to a file
means generating a print file that, when displayed, looks like the
printed page; that might be what the grayed-out file name in the KDE
dialog suggests as well (as it ends with ".ps").
People have, on occasion, asked how to "save a capture as text", or
something such as that. They usually probably mean they want what we
currently implement as printing to a file, so they might not be
expecting that to be available from the "Print..." dialog.
So should writing out a text summary (one line per packet) or detailed
view of a capture be considered "saving as text", "printing to a
file", or something else?
"Saving as text" is different from saving as a capture file -
information can be lost in that process (i.e., you don't get the raw
packet data unless you specify that the raw hex data should be shown),
a file saved as text can't be reloaded by Ethereal (and, no, I'm not
going to write the code to read that - and if it doesn't have the raw
hex data, that's *REALLY* hard to do!), and there are options that
don't apply to saving as a capture file (summary vs. detail, expand
all levels vs. show as displayed, show/don't show hex data).
Summarize this, it sounds to me that we might need an "export to raw
text" function or such. This could be a menu item in the File menu and
would make it more obvious (at least for me :-) that information might
get lost, when exporting to raw text.
But I just wanted to redesign the dialog to become more "readable" to
the user as a first step (as it was a bit of a mess before).
"Printing to a file" could be interpreted as saving a "print file" in
Postcript, PDF, Windows print metadata, etc. format - that seems to be
what the Mac OS X and KDE dialogs are implying, and I think I've
gotten some Windows applications to do that as well when I asked them
to print to a file. In addition, it might be that users don't expect
saving a text dissection of a packets to be done by printing.
Additional print range radiobuttons:
"All packets captured"
"Selected packet only"
"Packets from x to y"
How about "only packets currently being displayed", as is available
for "Save As"?
Thats what the "All packets displayed" radiobutton exactly is doing. In
the mail I only have mentioned things I would like to add in the future.
And, once we've done that, perhaps "selected packet only" and "packets
from x to y" should be available for "Save As". While we're at it,
should the "Save As" options show packet counts, as the "Print"
options do?
I would agree in both points. But I have some more things already
prepared (and going to commit them in the next days). Then I would like
to implement the things missing in the print dialog, before looking for
the next "open task" :-)
Regards, ULFL
