as that seems to be the name used in the GNOME HIG, at least. Make it
use the Warning icon (that's what the GNOME HIG says - and it's also
what's used for the equivalent on Windows), and use it for the "Save
current capture?" alert boxes.
svn path=/trunk/; revision=10030
simple_dialog routines (which are really just message box/alert box
routines).
Add some macros for combinations of buttons (corresponding to
combinations that some GUI toolkits, which only support some
combinations, allow).
svn path=/trunk/; revision=9977
using GTK2 primary/secondary message text from GNOME HIG for simple_dialogs,
added a "question dialog" for the coloring rules "Clear" button
svn path=/trunk/; revision=9921
"simple_dialog()"; NULL might be #defined to be a pointer expression on
some platforms, causing compiler warnings (and, on platforms where a
null pointer doesn't have all its bits 0, possibly causing misbehavior,
although I don't think there are any such platforms on which Ethereal
runs).
Don't allow 0 as button mask argument to "simple_dialog()".
Squelch a compiler warning.
Report fatal problems as errors, not warnings.
Report file I/O errors with "file_open_error_message()".
Report file write errors (including those reported by "close()", e.g.
some errors writing to an NFS server) when saving raw packet data to a
file.
svn path=/trunk/; revision=9915
interface name, look forward in the interface string for "\Device\", not
backwards for a space, on Windows. (Continue to look backwards for a
space on UNIX; names don't start with "\Device\", or even "/dev/", and
don't have spaces in them on any UNIX-flavored OS I know of.)
svn path=/trunk/; revision=9859
layouting the dialog buttons, and use it where appropriate.
This will help us with the GTK1/2 conflict on button layouts and
will also result in a more consistent look of the dialogs at all.
svn path=/trunk/; revision=9771
the interface isn't in the list of known (local) interfaces - that way
we don't try to get entries if the user's in the middle of changing the
"Interface:" text, or if the interface is an rpcap: URL (getting the
link-layer header type list for a remote interface is currently
impossible, and even just getting its *default* interface type could
hang for a long time if the remote machine isn't responding).
Free the link-layer header type list when we're done with it.
Label the option menu for that list "Link-layer header type", as it
doesn't control the data link type of the interface in the only case I
know of where it's settable, namely 802.11 interfaces - it just controls
whether the packets you get from the interface have a fake Ethernet
header or a real 802.11 header.
svn path=/trunk/; revision=8867
2.x) and transient-for setting that's done for other dialogs, and use it
for dialogs that come from the main window or from children of the main
window.
svn path=/trunk/; revision=8531
Capture Options dialog box to the first string in the combo box, not to
the first interface name in the list, so we get the description.
svn path=/trunk/; revision=8444
containing a pointer to an interface name and possibly a pointer to an
interface description (although that pointer might be null if no
description is available), rather than having the Windows version glue
together the name and description into a single string.
Supply for the Linux "any" device the same description that libpcap's
"pcap_findalldevs()" returns.
svn path=/trunk/; revision=8440
support for user-supplied interface descriptions;
support for hiding interfaces in drop-down list in capture
dialog.
Clean up comments written to preferences file.
svn path=/trunk/; revision=8419
when the new "Rotate capture file every n second(s)" checkbox or the
-b <# of file>[:<duration>] argument are used, [t]ethereal will skip to the
next ring buffer file if the specified duration has elapsed (even if the
specified capture size is not reached). This is useful when you want to have
separate capture files per hour or day for instance.
I let the autostop filesize parameter mandatory (i.e. the "rotate capture
file after n kilobytes") but this could be no longer strictly necessary when
that new feature is used ...
Another point: it might be interesting to really truncate the file at the
switch and not the closure ... According to user comments and my own real
case tests, I might plan to enhance this point and others (still ring buffer
related) in the future.
svn path=/trunk/; revision=7678
"destroy" signal handler for any button that pops up a filter; if the
button has a filter dialog box associated with it, it destroys that
dialog box.
Have the routines that create filter dialog boxes asociate the dialog
box with the button that created it, so that if the button is destroyed
the filter dialog box can be destroyed as well, and associate the button
with the dialog box.
This means that if a dialog box has a button to create a filter, we no
longer have to have the destroy handler for the dialog box destroy any
filters - that'll happen when the button in the dialog box is destroyed
as part of the process of destroying the dialog box.
Don't make the "Filter" buttons in the io_stat dialog box insensitive if
there's already a filter dialog box open - we can have more than one
open per dialog box.
svn path=/trunk/; revision=6930
In my recent patches to set and use a default directory, I neglected
to set the directory when the user enters a file name directly into the
"Capture Options" and "Print" dialogs instead of using the file dialog.
This set of patches corrects this.
svn path=/trunk/; revision=6318
Currently Ethereal sets and uses a default directory for reading
and writing, but only in some places. This set of patches extends
the setting of the default directory to the -w option as well as
the -r option, and causes all file dialogs to use and set the
default consistently. (I haven't changed the
Preferences/Printing/File dialog, though, as that's a special
case.)
There's also a fix for a bug where Ethereal was issuing the
message "Ring buffer requested, but capture isn't being saved to
a permanent file" even though a file was specified with -w.
There also appear to be some other cleanups in his patch.
svn path=/trunk/; revision=6238
dftest.c:
Remove #if-0-ed includes
packet-ieee80211.c, packet-wtls.c, packet-afp.c, packet-wsp.c,
packet-wtp.c, ethereal_gen.py:
Remove redundant include varargs (already in snprintf.h,
and required only for snprintf.h)
Remove unused include of snprintf.h from files not using
"snprintf()".
svn path=/trunk/; revision=5889
Move the ringbuffer capture options from the "capture_file" structure to
the structure for capture options, as they're a property of an
in-progress capture, not a property of a particular capture file.
svn path=/trunk/; revision=4799
"capture_file" structure - they're a property of an in-progress capture,
not a property of an open capture file. Make them just variables.
The maximum number of packets to be captured should be a variable
separate from the "count" field in the "capture_file" structure - the
latter is a count of the packets in the capture file in question.
Have Boolean variables indicating whether a maximum packet count,
maximum capture file size, and maximum capture duration were specified.
If an option isn't set, and we're doing an "update list of packets in
real time" capture, don't pass the option to the child process with a
command-line argument.
Don't create "stop when the capture file reaches this size" or "stop
when the capture's run for this long" conditions if a maximum capture
file size or a maximum capture duration, respectively, haven't been
specified. Don't test or free a condition if it wasn't created.
Don't allow a 0 argument to the "-c" flag - the absence of a "-c" flag
is the way you specify "no limit on the number of packets".
Initialize the check boxes and spin buttons for the "maximum packets to
capture", "maximum capture size", and "maximum capture duration" options
to the values they had in the last capture. If an option wasn't
specified, don't read its value from the dialog box and set the
variable.
svn path=/trunk/; revision=4795
reading the capture file. Have callers of "wtap_snapshot_length()"
treat a value of 0 as "unknown", and default to WTAP_MAX_PACKET_SIZE (so
that, when writing a capture file in a format that *does* store the
snapshot length, we can at least put *something* in the file).
If we don't know the snapshot length of the current capture file, don't
display a value in the summary window.
Don't use "cfile.snap" as the snapshot length option when capturing -
doing so causes Ethereal to default, when capturing, to the snapshot
length of the last capture file that you read in, rather than to the
snapshot length of the last capture you did (or the initial default of
"no snapshot length").
Redo the "Capture Options" dialog box to group options into sections
with frames around them, and add units to the snapshot length, maximum
file size, and capture duration options, as per a suggestion by Ulf
Lamping. Also add units to the capture count option.
Make the snapshot length, capture count, maximum file size, and capture
duration options into a combination of a check box and a spin button.
If the check box is not checked, the limit in question is inactive
(snapshot length of 65535, no max packet count, no max file size, no max
capture duration); if it's checked, the spinbox specifies the limit.
Default all of the check boxes to "not checked" and all of the spin
boxes to small values.
Use "gtk_toggle_button_get_active()" rather than directly fetching the
state of a check box.
svn path=/trunk/; revision=4709
"epan/..." pathnames, so as to avoid collisions with header files in any
of the directories in which we look (e.g., "proto.h", as some other
package has its own "proto.h" file which it installs in the top-level
include directory).
Don't add "-I" flags to search "epan", as that's no longer necessary
(and we want includes of "epan" headers to fail if the "epan/" is left
out, so that we don't re-introduce includes lacking "epan/").
svn path=/trunk/; revision=4586
Separate the preferences value for those flags and the name resolution
code's value into separate variables; this means that the resolution
code no longer depends on the preferences code, and may let us
eventually have the current setting and the preference setting differ
(so that a user can temporarily override the preference setting without
causing subsequent saves of the preferences to save the temporary
value).
Add routines to create various types of widgets for preferences, and to
fetch the values for "enumerated" preferences, and use them both in the
code to handle hardwired preference pages and table-driven preference
pages.
svn path=/trunk/; revision=4536
"Capture Preferences", to avoid confusion with the "Capture" item in the
"Preferences" dialog (which sets the initial default values for the
"Capture Options" dialog).
svn path=/trunk/; revision=4523
and "Automatic scrolling in live capture" options from the preference
settings for them, so that the preference settings affect the initial
values of those options, but changing those values in a capture don't
affect the preferences, and don't automatically get saved when you save
the preferences.
If we're building without libpcap, don't have an "Automatic scrolling in
live capture" option anywhere.
svn path=/trunk/; revision=4514
