enumerated option lists. This to overcome a small bug in which the
menu item text doesn't have enough vertical padding.
svn path=/trunk/; revision=2868
for the dialog window as an argument (as various dialog creators in GTK+
do), not oblige every caller of it to cut-and-paste a
"gtk_window_set_title()" call after it.
svn path=/trunk/; revision=2345
"cancel", and "delete" methods, give them:
"fetch" - fetch from the notebook tab any values not already
stored in "prefs", and store them there, but doesn't apply them;
"apply" - apply the settings in "prefs";
"destroy" - clean up any windows created from the tab.
As we no longer have "cancel" methods, we don't have per-preference code
to revert preference values; instead, we have the common preference
dialog box code make a copy of all the current preferences, and, when
the "Cancel" button is clicked, free the current preferences and copy
the saved preferences to it, and apply the preferences.
Add an "Apply" button to the preference dialog box, which applies the
current preferences without closing the dialog box.
Treat a request to delete the preferences dialog box as equivalent to
clicking "Cancel".
Have a "remember_ptree_widget()" routine to remember all protocol tree
widgets, and use the list of those widgets when we set GUI preferences
for the protocol tree widgets, rather than setting the main protocol
tree widget and then using the list of packet windows. Move that code
out of "main.c" to "proto_draw.c", as it's not used by anything in
"main.c", but is used by stuff in "proto_draw.c".
Make the font one of the preferences we can set on the fly for protocol
tree widgets. Also make it something we can set on the fly for the
packet list widget.
svn path=/trunk/; revision=2316
explicitly; the right thing to do was to have
"remember_scrolled_window()" catch the "destroy" signal on the scrolled
window widget, and have the handler for that signal forget the scrolled
window.
Doing that obviates the need to have creators of scrolled windows keep
track of the windows they have and forget them when they're destroyed.
The signal for a "the window manager has requested that this window go
away" event is "delete_event", not "delete-event"; fix the
"gtk_signal_connect()" calls that were using "delete-event".
svn path=/trunk/; revision=2284
at the correct notebook page when a particular protocol (which has registered
some preferences) is selected in the tree view.
- add set_menus_for_selected_tree_row() in menu.[ch]
- add prefs_is_registered_protocol() and
prefs_get_title_by_name() in prefs.[ch]
svn path=/trunk/; revision=2275
- 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
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
Gilbert Ramirez