> I am returning to my examination of colorization of the ethereal summary
> display. I hope to start working on it RSN. As a result of previous
> discussions, I'd like to have filters to select the packets to colorize.
> (e.g. ip.addr == 10.4.0.2) and then be able to set that to, say, blue.
> This seems to imply:
> 1 the frame_data structure needs an array or list of color
> filter structs
Presumably you mean "an array or list of references to color filter
structs"; it sounds as if the idea is that there would be N color
filters in effect, e.g.:
ip.addr == 10.4.0.2 puce
arp lavender
tcp.port == 80 teal
and adding a new color filter would cause that filter to be applied to
all packets, with the packet's summary line made that color if the
filter matches, and a reference to the filter added to the packet's
"frame_data" structure if it matches as well. Changing the color of a
filter would just require scanning the packet list and changing all
packets that have references to the filter in question (so you don't
have to apply the filter again).
What should happen if more than one color filter selects a packet? (Pick
the first? Pick the last? Pick one at random? Pick some mix of the
colors?)
> 2 color filter structs need to have the filter string, compiled
> filter and color
Compiled filter is an optimization; you could recompile it as necessary.
> 3 the color filter list or array needs to be processed as
> data is put into the summary window
...or when a filter's color is changed, or a new filter is added.
I infer from the existence of "gtk_clist_set_foreground()" and
"gtk_clist_set_background()", and from the fact that they both have
"row" as one argument, that the color of a GtkClist row can be set on
the fly, without affecting other rows; this would mean that when a
filter's color is changed or a new filter is added, the summary window's
data doesn't have to be updated, just the colors of the rows affected by
the filter.
> 4 there needs to be a way to enter a list of colorizing filters
> (and eventually select colors from a pallette).
Yes; note that GTK+ has a color-selection dialog box already (with
sliders to let the geekier members of the audience tweak RGB or HSV
directly, and a color wheel for the less-geeky members of the audience;
a color palette of "basic" colors, like the one the Windows
color-selection dialog box has, might also be nice, although that should
probably just be added to GTK+'s color-selection dialog. (The Windows
box, in its full shining glory, has:
48 "basic colors", at least on my whizzo 24-bit monitor (it
probably limits that on a 16-color display, say);
room for 16 "custom colors", which probably get stored somewhere
in your private steaming heap of registry keys;
a color spectrum (sort of like the color wheel, but with
rectangular rather than polar coordinates);
a bunch of text entry boxes for HSL (luminosity) and RGB, for
the geekier members of the audience;
where the "basic" setting just shows the basic and custom colors, and
you can click on a "Define Custom Colors" button to get the Full Frontal
Dialog Box.)
