values to the ones specified in the dialog box, so it should also
redissect the packets and re-evaluate the display filter if any of them
changed. (I.e., it did part of an "Apply"; it needs to do all of it.)
"Cancel" also needs to find out if any preferences were changed by the
reversion and redissect and refilter if they did.
svn path=/trunk/; revision=2132
a word to use in the progress dialog, and a flag indicating whether the
display filter is to be reevaluated or not, and:
have "colorize_packet()" call that routine with "Colorizing" and
FALSE as those arguments;
have the filtering code call that routine with "Filtering" and
TRUE as those arguments;
add an exported routine to call that routine with "Reprocessing"
and TRUE as those arguments, to use to re-generate the packet
list and to re-filter the packets if a protocol preference has
been changed.
Keep track of whether preferences are changed from their initial value
by a preferences file or a command-line option, or from their previous
value by the "Preferences" dialog box; have "prefs_apply_all()" only
call the "apply" callback for a module if they have.
Call "prefs_apply_all()" after the command-line arguments have been
parsed and after "OK" has been clicked in the "Preferences" dialog box,
to notify modules of preference changes if they've registered a callback
for that.
After "OK" has been clicked in the "Preferences" dialog box, if any
preferences have changed, call the reprocessing routine, as the summary
line for some frames and/or the current display filter's value when
applied to some frames may have changed as a result of a preference
change. Do the same after "OK" or "Apply" has been clicked in the
"Display Options" dialog box (as it controls a protocol preferences
item.
svn path=/trunk/; revision=2126
same directory as the "manuf" file ("/etc" or "/usr/local/etc", most
likely).
Add a mechanism to allow modules (e.g., dissectors) to register
preference values, which:
can be put into the global or the user's preference file;
can be set from the command line, with arguments to the "-o"
flag;
can be set from tabs in the "Preferences" dialog box.
Use that mechanism to register the "Decode IPv4 TOS field as DiffServ
field" variable for IP as a preference.
Stuff that still needs to be done:
documenting the API for registering preferences;
documenting the "-o" values in the man page (probably needs a
flag similar to "-G", and a Perl script to turn the output into
documentation as is done with the list of field);
handling error checking for numeric values (range checking,
making sure that if the user changes the variable from the GUI
they change it to a valid numeric value);
using the callbacks to, for example, update the display when
preferences are changed (could be expensive);
panic if the user specifies a numeric value with a base other
than 10, 8, or 16.
We may also want to clean up the existing wired-in preferences not to
take effect the instant you tweak the widget, and to add an "Apply"
button to the "Preferences" dialog.
svn path=/trunk/; revision=2117
dialog select a particular page - I think that was used only by the
filter code back when "Filter:" buttons popped up a Preferences dialog
with the Filter page (which is no longer a Preferences dialog page)
selected, but now there's a separate Filter dialog box.
svn path=/trunk/; revision=2116
window and makes it transient for the top-level window; the
transient-for at least provides a hint to X window managers to
minimize the dialog if the main window is minimized;
keep the dialog on top of the main window in the Z order for
windows;
perhaps (if there are any window managers that actually *do*
this) even put it atop the main window in the X-Y plane (KWM
doesn't and I seem to remember that the Exceed X server for
Windows doesn't).
It's generally considered the Right Thing To Do for dialog boxes.
Use that routine to create dialog boxes, rather than doing it directly
in the code for that dialog box.
svn path=/trunk/; revision=2112
pointer is NULL - so that, instead of doing nothing if the user selects
"Edit->Preferences" when there's already a "Preferences" dialog box
open, we raise and de-iconify that window.
Connect the preferences dialog box and any file selection dialog box
opened from its Print tab, so that:
if the preferences dialog box goes away, so does the file
selection dialog box (as it no longer has a text widget into
which it can stuff the selected file name);
if the "File:" button is clicked when there's already a file
selection dialog box open, we just reactivate that existing
dialog box rather than popping up a new one.
Catch the ESC key in the file selection dialog box popped up for the
"File:" button in the Print tab of the Preferences dialog box, and make
it cancel the file selection dialog box.
svn path=/trunk/; revision=1922
into "gtk/column_prefs.c".
Get rid of "get_column_width()" - instead, export
"get_column_longest_string()", and have "get_column_width()"'s callers
make the GDK call to get the width of that string, so that "column.c"
contains no GTK+/GDK code.
svn path=/trunk/; revision=1447
the preferences file fails, have it return an error indication and the
path of the preferences file, and have its caller display the dialog
box. That way you don't have to drag in the dialog box code if you're
going to use the preferences code in, say, a "line-mode" Ethereal.
svn path=/trunk/; revision=1413
that you don't have to have "gtk/prefs_dlg.c" to get it defined - future
non-GTK (text mode, curses, etc.) programs wouldn't have it.
svn path=/trunk/; revision=1387
option right now is the placement of the vertical scrollbars in the 3 panes.
(it's one decision; you can't have the placement of the vertical scrollbar
in the packet list pane different than the placement in the protocol tree
pane, for example).
I did this because I find it convenient to have the vertical scrollbars
on the *left* side of the text. My mouse cursor is usually expanding and
collapsing the protocol tree widgets, and once the protocol tree changes
size, I usually have to scroll. I'd rather move my mouse cursor just a few
pixels over to find the vertical scrollbar.
svn path=/trunk/; revision=1351
"Edit:Preferences" and put it directly under "Edit:Filters", and to add
an "Apply" button to it, which makes the currently selected filter the
current filter and applies it to the current capture.
svn path=/trunk/; revision=1275
- that event happens if, say, you nuke the dialog box from a window
manager - and call "delete" routines for each of the preferences tabs,
so that, for preferences tabs that include list widgets, we can set a
flag on the preferences tab widget telling the selection callback for
the list widget that the buttons it would normally set the sensitivity
of, based on whether any row in the list is selected or not, have Joined
the Choir Invisible, and therefore that we shouldn't change their
sensitivity because GTK+ will whine at us if we do, just as is the case
if we press the "OK" or "Cancel" button (which also cause the window to
go away).
Can we just do this in the "window delete" handler? I.e., does that get
called if we explicitly destroy the widget? Or should we catch a
"destroy" event instead?
(There must be a better way to do this....)
svn path=/trunk/; revision=647
