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
display tree, based on Jeff Foster's dialog box for selecting fields.
Make the dialog box for browsing filters into a dialog box for
constructing filters; make the "Apply" button and the "OK" button apply
the filter in the text entry box in the dialog, not the currently
selected filter (selecting a filter puts it in that text entry box, but
the user may edit it afterwards, or may use the aforementioned dialog
box to construct a filter not in the list).
Get rid of extra declarations of "m_r_font" and "m_b_font" in
"proto_draw.c"; they're declared in "gtk/gtkglobals.h", which it includes.
svn path=/trunk/; revision=2805
Guy Harris