without having to delete them. The patch has been tested on
Fedora-7 with GTK+ 1.2.10 and GTK+ 2.10.11.
Since I don't know how to use "strikethrough" in clists in GTK1
there is a little difference in how the disabled coloring rules
are displayed. In GTK2 they are striked through and in GTK1
they are shown in lightgrey on a white background.
Any info on how to use strikthrough in clists within GTK1 is more
than welcome :-)
svn path=/trunk/; revision=23421
but toolkit-dependent implementations, for manipulating colors, and have
"gtk/color_utils.h" declare them (the header file should eventually be
moved to the top-level directory). Move the routines to convert between
GdkColor and color_t out of there into "colors.c", and move their
declarations into "colors.h", as their APIs are toolkit-dependent.
Have the first such routine be a "create_color()" routine, which takes
RGB values and initializes a "color_t", including doing any
toolkit-dependent work necessary for that; use that in the
"gtk/color_filters.c" code (the goal is to remove as many of the toolkit
dependencies as possible from that code, and move it to the top-level
directory).
svn path=/trunk/; revision=11497
they have LF at the end of the line on UN*X and CR/LF on Windows;
hopefully this means that if a CR/LF version is checked in on Windows,
the CRs will be stripped so that they show up only when checked out on
Windows, not on UN*X.
svn path=/trunk/; revision=11400
- moved color_filter_t in color.h
- change color_filter_t to use color_t instead of GdkColor
This changed allowed to remove the last gtk includes in file.c. It is
now completely free of any gtk related code.
svn path=/trunk/; revision=6324
"colfilter" structure contained items of use only when the colorizing
dialog was up, so make the items in it private to "gtk/color_dlg.c".
Make the "Edit" and "Delete" buttons sensitive only when a row is
selected, and make the "Up" and "Down" buttons sensitive only when a row
is selected *and* that row has somewhere to move in the specified
direction.
svn path=/trunk/; revision=5575
"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
Put a hash-table of "interesting" fields in the per-proto-tree data.
The dfilter code records which fields/protocols are "interesting" (by which
I mean, their value or existence is checked). Thus, the proto_tree routines
can create special arrays of field_info*'s that are ready for the dfilter
engine to use during a filter operation.
Also store the "proto_tree_is_visible" boolean, renamed "visible", in
the per-proto-tree data.
Move epan_dissect_t to its own header file to make #include dependencies
easier to handle.
Provide epan_dissect_fill_in_columns(), which accepts just the epan_dissect_t*
as an argument.
epan_dissect_new() needs to be followed by epan_dissect_run() for the
dissection to actually take place. Between those two calls,
epan_dissect_prime_dfilter() can be run 0, 1, or multiple times in order to
prime the empty proto_tree with the "intersesting" fields from the dfilter_t.
svn path=/trunk/; revision=4422
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
- add <stdarg.h> or <varargs.h> in snprintf.h
and remove those inclusions in the other #ifdef NEED_SNPRINTF_H codes
- remove the check of multiple inclusions in source (.c) code
(there is a bit loss of _cpp_ performance, but I prefer the gain of
code reading and maintenance; and nowadays, disk caches and VM are
correctly optimized ;-).
- protect all (well almost) header files against multiple inclusions
- add header (i.e. GPL license) in some include files
- reorganize a bit the way header files are included:
First:
#include <system_include_files>
#include <external_package_include_files (e.g. gtk, glib etc.)>
Then
#include "ethereal_include_files"
with the correct HAVE_XXX or NEED_XXX protections.
- add some HAVE_XXX checks before including some system header files
- add the same HAVE_XXX in wiretap as in ethereal
Please forgive me, if I break something (I've only compiled and regression
tested on Linux).
svn path=/trunk/; revision=2254
the color-selection and color-filter-editing GUI stuff; different
toolkits, and different windows systems, have their own notions of color
objects - they may have nothing in common other than the notion that
colors have red, green, and blue values); move it all to the "gtk"
subdirectory for now, and, as we discover stuff stuff that can be made
platform-independent, drag it up to the top-level directory.
svn path=/trunk/; revision=1621
Sake Blok