Mac OS X
GNOME
Qt
KDE
Windows
all indicate that {message,alert} boxes are modal, at least for the
window to which they apply. (Presumably the idea is that not forcing
the user to pay attention to the alert box, and allowing more than one
alert box to be up for a given window, causes more problems than not
letting the user do stuff to that window in order to figure out what the
underlying problem is or figure out what to do to fix it - the message
should be sufficient, in most if not all cases, to let you know what the
problem is.)
Make "simple_dialog()" unconditionally make the alert box modal, and get
rid of ESD_TYPE_MODAL. XXX - we need to make it possible to make an
alert box modal for a given window, rather than just the top-level
window.
svn path=/trunk/; revision=10051
scrolled_window_new().
added gtk_scrolled_window_set_policy(AUTOMATIC,AUTOMATIC) to
scrolled_window_new()
added GTK2's gtk_scrolled_window_set_shadow(GTK_SHADOW_IN)
to every place needed
svn path=/trunk/; revision=9999
"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
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
This function is also very small, so small that teh overhead for the actual function call and return is likely to be a significant part
of its execution time.
change it into a macro and make it thus slightly faster by eliminating the function call overhead.
svn path=/trunk/; revision=9083
Make "proto_is_protocol_enabled()" and "proto_get_protocol_short_name()"
take a "protocol_t *" as an argument, so they don't have to look up the
"protocol_t" - this will probably speed them up considerably, and
they're called on almost every dissector handoff.
Get rid of a number of "proto_is_protocol_enabled()" calls that aren't
necessary (dissectors called through handles, including those called
through dissector tables, or called as heuristic dissectors, aren't even
called if their protocol isn't enabled).
Change some direct dissector calls to go through handles.
svn path=/trunk/; revision=8979
probably be variable-width, so that doesn't work. Just put a dash
between them.
Boost the size of the buffer used for the field text to 256 characters.
In GTK+ 1.2[.x], put the entries for fields (rather than protocols) in
as leaf nodes.
svn path=/trunk/; revision=8388
It was very cnfusing where some protocols such as SMB had multiple items all called the same thing. Now one can distinguish between them
svn path=/trunk/; revision=8383
support for registering fields after all the protocol
registration routines are called (i.e., adding fields to the
named field tree as they're registered);
fix the GTK 2.x version of the field list dialog to show the
correct name.
svn path=/trunk/; revision=8248
Besides "STRING", there is now "UNPARSED_STRING", where the distinction
is that "STRING" was a double-quoted string and "UNPARSED_STRING" is just
a sequence of characters that the scanner didn't know how to scan/parse,
so it's up to the Ftype to parse it.
This gives us more flexibility and prepares the dfilter parsing engine
for the upcoming addition of the "contains" operator.
In the process of doing this, I also re-did the double-quoted string
support in the scanner, so that instead of the naively-simple support we
used to have, double-quoted strings now can have embedded dobule-quotes,
embedded octal sequences, and embedded hexadecimal sequences:
"\"" embedded double-quote
"\110" embedded octal
"\x48" embedded hex
Enhance the dfilter unit test script to be able to run a single collection
of tests instead of having to run all of them all the time.
svn path=/trunk/; revision=8083
to be using it for stuff that should be hex, and for stuff that should
be Boolean. Use BASE_DEC if it should be decimal, BASE_HEX if it should
be hex, and make it Boolean if it should be Boolean.
svn path=/trunk/; revision=7053
based on the user's UI preferences, and add them to a list of GtkCTrees.
Use those routines to create all GtkCTrees.
Have a routine to update the preferences for all of those GtkCTrees.
Call that routine whenever the preferences change.
Label the line and expander style preferences as "Tree line style" and
"Tree expander style", as they no longer apply only to protocol trees.
Move the routines to maintain a list of scrolled windows, and to update
scrollbar placement for scrolled windows, to "ui_util.c".
svn path=/trunk/; revision=4520
directory in which global data files are stored. If an installed binary
is being run, that's the correct directory for them; if a build-tree
binary is being run, the "manuf" file will be there, and you can put
other data files there as well, if necessary.
Do the same with plugins, except that, if there's no
"plugins\\{version}" subdirectory of that directory, fall back on the
default installation directory, so you at least have a place where you
can put plugins for use by build-tree binaries. (Should we, instead,
have the Windows build procedure create a subdirectory of the "plugins"
source directory, with the plugin version number as its name, and copy
the plugins there, so you'd use the build-tree plugin binaries?)
Move "test_for_directory()" out of "util.c" and into
"epan/filesystem.c", with the other file system access portability
wrappers and convenience routines. Fix "util.h" not to declare it - or
other routines moved to "epan/filesystem.c" a while ago.
svn path=/trunk/; revision=3858
without a comparison operator, it tests for the field's presence or
absence, not its value; to test whether a Boolean field is true, you
compare it with a non-zero value, and to test whether it's false, you
compare it with a zero value.
Make the filter expression construction dialog handle that correctly.
svn path=/trunk/; revision=3068
and, when it's being destroyed, disconnect from the "destroy" signal on
the text entry box to which it's attached, so that, when that text entry
box is destroyed, we don't try to get rid of the no-longer-extant
filter-expression-construction dialog.
svn path=/trunk/; revision=3061
filter-expression-construction dialog box is attached; if the text entry
box is destroyed (which typically means the window it's in was
destroyed), get rid of the filter-expression-construction dialog box.
svn path=/trunk/; revision=3060
available for it and it looks ugly" is "throw an alignment around it".
(I *still* don't know why it's not required in other dialog boxes, e.g.
the filter-editing dialog box.)
svn path=/trunk/; revision=3059
expression construction dialog activate the entire dialog box.
Make a desperate but failed attempt to bludgeon GTK+, The Toolkit That
Knows Better Than You Do How Big Buttons Should Be Made, Even If It
Looks Butt-Ugly, And Which Appears To Randomly Decide Whether To Make It
Look Ugly Or Not, into making the "Cancel" button as tall as the inside
of the "Accept" button, not as tall as the "Accept" button plus its
"this is the default button" surround.
svn path=/trunk/; revision=3057
fields.
Show a relational operator on a field if the field supports it *or* if
the field can be sliced and the type generated by a range (FT_BYTES)
supports it. (This lets you do a comparison on a protocol, not just on
a range of a protocol - e.g., "arp == 2", not just "arp[0:1] == 2" - but
the alternative would be to show only the "is present" test, as if you
don't offer the other tests, you can't turn on the range text box when
they select a comparison expression if you don't show comparison
expresions...).
svn path=/trunk/; revision=3056
in the output of "{ethereal,tethereal} -G", so that it appears only once
in the documentation.
Expand some comments to give more details.
svn path=/trunk/; revision=3024
can now handle that; this allows us to register both the modulo-8 and
the modulo-128 versions of various X.25 bitfields with "x.25.XXX" names,
which lets us get rid of the "ex.25" protocol stuff completely and use
"x.25" for both modulo-8 and modulo-128 X.25. Do so. (Also, fix up
some cases where we appeared to be using the modulo-8 fields when
dissecting modulo-128 X.25.)
This, in turn, allows us to register the X.25 dissector, as there's now
only one protocol with which it's associated, and make it static and
have it called only through a handle, and to, when registering it with
the "llc.dsap" dissector table, associate it with "proto_x25".
That, in turn, allows us to get rid of the "CHECK_DISPLAY_AS_DATA()"
calls, and the code to set "pinfo->current_proto", in the X.25
dissector.
The code for the display filter expression dialog would, if there are
two fields with the same name registered under a protocol, list both of
them; have it list only one of them - the fields should have the same
type, the same radix, and the same value_string/true_false_string table
if any (if they don't, they're really not the same field...).
svn path=/trunk/; revision=3023
into epan/ftypes.
Re-write display filter routines using Lemon parser instead of yacc.
Besides using a different tool, the new grammar is much simpler, while
the display filter engine itself is more powerful and more easily extended.
Add dftest executable, to test display filter "bytecode" generation.
Add option to "configure" to build dftest or randpkt, both of which are not
built by default.
Implement Ed Warnicke's ideas about dranges in the new display filter and
ftype code.
Remove type FT_TEXT_ONLY in favor of FT_NONE, and have protocols registered
as FT_PROTOCOL. Thus, FT_NONE is used only for simple labels in the proto tree,
while FT_PROTOCOL is used for protocols. This was necessary for being
able to make byte slices (ranges) out of protocols, like "frame[0:3]"
Win32 Makefile.nmake's will be added tonight.
svn path=/trunk/; revision=2967
protocols, in addition to adding structures to the list of filterable
fields. Give it an extra argument that specifies a "short name" for the
protocol, for use in such places as
pinfo->current_proto;
the dialog box for constructing filters;
the preferences tab for the protocol;
and so on (although we're not yet using it in all those places).
Make the preference name that appears in the preferences file and the
command line for the DIAMETER protocol "diameter", not "Diameter"; the
convention is that the name in question be all-lower-case.
Make some routines and variables that aren't exported static.
Update a comment in the ICP dissector to make it clear that the
dissector won't see fragments other than the first fragment of a
fragmented datagram.
svn path=/trunk/; revision=2810
the value entry on the type of the field, not on whether the value entry
is visible; the value entry is hidden, in "field_select_row_cb()", after
"build_boolean_values()" is called, and building the list in
"build_boolean_values()" will cause an entry in that list to be
selected, and "value_list_sel_cb()" will be called as a result, so it
can't correctly base its decision on whether to set the value entry on
whether the entry is visible, as it's not yet been made invisible.
Fix a comment.
svn path=/trunk/; revision=2807
