|Age||Commit message (Collapse)||Author||Files||Lines|
obsolete; we silently ignore attempts to set those in a preferences
file, so that we don't spam the user with error messages caused by them
having saved preferences in an earlier release that contained those
Make the Diameter and iSCSI dissectors register obsolete preferences.
Crash if some code tries to register a preferences module with a name
that contains something other than lower-case ASCII letters, numbers, or
underscores, or that has already been registered, or if some code tries
to register a preference with a name that contains something other than
lower-case ASCII letters, numbers, underscores, or periods, or that has
already been registered, so that we don't put code like that in a
release and have to shovel code into "prefs.c" to fix it up later. (The
problem with multiple modules or preferences with the same name should
be obvious; the problem with names with blanks, or upper-case letters,
or punctuation, is that they're a pain to type on the command line.)
svn path=/trunk/; revision=4148
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
reside. Use it, rather than concatenating the user's home directory and
".ethereal" in a number of files.
Fix up some additional places to use G_DIR_SEPARATOR_S as the pathname
svn path=/trunk/; revision=4061
we can say more than just that there was a "Syntax error" in the
svn path=/trunk/; revision=3772
Support for saving to the preferences file the settings for all types of
Do a case-insensitive check for "true" and "false" in Boolean preference
svn path=/trunk/; revision=3489
and never was - there's only an Ethereal-wide "enable name resolution"
preference. Name it just "name_resolve".
Replace all tests of "g_resolving_actif" with tests of
"prefs.name_resolv", and replace all code that sets "g_resolving_actif"
with code that sets "prefs.name_resolv", so that the setting of
"prefs.name_resolv" actually affects whether names are resolved or not.
svn path=/trunk/; revision=3300
svn path=/trunk/; revision=3298
"prefs_register_module()" except that it takes a protocol index as
returned by "proto_register_protocol()" as its first argument, rather
than taking two character strings as arguments as its first two
arguments, and uses the protocol's abbreviation as the name to use for
preferences in the preferences file and the "-o" flag and uses the
protocol's short name as the name to use in the tabs in the
svn path=/trunk/; revision=2812
"color_t" structure to store color values (although currently it has all
the same fields that a GdkColor has; its currently advantage is that you
don't have to include any GTK/GDK stuff to declare it).
Add routines in the "gtk" directory to convert between "color_t" and
Define, in "prefs.h", all colors as "color_t" values rather than
GdkColor values. "prefs.h" now no longer needs to include <gtk/gtk.h>,
so don't include it.
svn path=/trunk/; revision=2692
PLUGINS_NEED_ADDRESS_TABLE was defined.
svn path=/trunk/; revision=2662
highlighting of the bytes, in the hex dump window, corresponding to a
Also, make "remember_ptree_widget()" static, as it's not used outside
svn path=/trunk/; revision=2399
color of marked frames.
They are currently only available from preferences file,
but I will add the color selection in GUI later.
svn path=/trunk/; revision=2327
"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
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
generate the name of the boldface font from the Roman font; if the two
fonts don't have the same widths, the display will look weird when a
field is selected, and it's a bit of a pain for the user to have to
select *two* fonts.
On UNIX/X, default to
"-*-fixed-medium-r-semicondensed-*-*-120-*-*-*-*-*-" rather than to
"-*-lucidatypewriter-medium-r-normal-*-*-120-*-*-*-*-iso8859-1" - some
Linux distributions appear to lack the Lucida typewriter font.
Add a "gui.font_name" preference to the preferences file, specifying the
normal-weight font to use. Have it settable from the "GUI" tab in the
Preferences dialog box - the "Font..." button, when clicked, pops up a
font selection dialog box.
If we either can't open the selected font or the boldfaced version of
the font, default to "6x13" and "6x13bold" as fallbacks - the former
will probably be "fixed", and the latter would be "fixedbold" if X
actually created such an alias, but it doesn't so we use "6x13bold"
svn path=/trunk/; revision=2304
(the name should match the one specified at the proto_register_protocol() call).
svn path=/trunk/; revision=2287
svn path=/trunk/; revision=2276
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
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
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
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
svn path=/trunk/; revision=2126
same directory as the "manuf" file ("/etc" or "/usr/local/etc", most
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"
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
support for printing in PostScript to the "Print..." dialog box.
svn path=/trunk/; revision=1426
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
svn path=/trunk/; revision=1400
I did this:
First, Havoc Pennington, in "GTK+/Gnome Application Development", in
Appendix seciton A.3.88, recommends using GtkCTree instead of GtkTree
because GtkCtree is faster, and GtkTree has limitation on its total row
height: since it must fit inside a GdkWindow, it is limited to 32,768
pixels of height. GtkTree is more flexible with regards to the types of
widgets that can be placed in the tree, but since we deal only with text,
that doesn't matter, at least for now.
Secondly, a GtkTree doesn't allow arrow-key navigation (at least as far
as I could tell). It always bothered me that the up and down arrow keys
worked in the packet list and in the hex dump, but no in the protocol tree.
GtkCTree does allow arrow-key navigation. In fact, GtkCTree is a subclass
of GtkCList (the packet list widget), so they behave a lot alike.
I went ahead and fixed the selection bar which has been bothering Richard
for a long time now. :) In the GUI preferences dialogue, you can now set
both the packet list selection bar and the protocol tree selection bar
to either "browse" or "select" mode. "browse" mode is what you're used to:
the arrow keys move an outline of the selection bar, but do not change
the selection. "select" mode does change the selection when the arrow keys
are pressed. The default behavior is set to "select", which seems more
natural for a first-time user.
svn path=/trunk/; revision=1393
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
summary.c now provides a struct of info (see summary.h)
Changed the name of the summary dialogue callback (hence the change
in menu.c), and added a close button to the dialogue.
Moved #include <gtk/gtk.h> out of print.c and into prefs.h where it
was needed for GdkColor.
svn path=/trunk/; revision=1273
may not work with pseudocolor systems.
svn path=/trunk/; revision=1179
svn path=/trunk/; revision=636
capture to a file or printer. This should eventually get the ability to
print either all the packets or only the packets selected by the display
filter, and possibly also the ability to print only packets M through N.
Get rid of "cur" member of "capture_file" structure; nobody used it.
There's no need to pass a pointer to a "dialog_button" variable to
"simple_dialog()" for the error boxes displayed if a file copy or move
fails; that dialog box is just a message box and has only an "OK"
Put the declaration of "prefs" into "prefs.h".
svn path=/trunk/; revision=378
we've shown the top-level window, because we want it to pop up on *top*
of the top-level window, rather than being hidden behind it.
Put a "strerror()"-based reason *why* the open failed in that dialog.
svn path=/trunk/; revision=308
* Added check_col(), add_col_str() and add_col_fmt() to replace references
* Added column prefs handling code.
svn path=/trunk/; revision=97
svn path=/trunk/; revision=75
- Separated display and capture filters; rearranged some of the look and feel
- Lots of other miscellaneous fixes and updates
svn path=/trunk/; revision=38
* FDDI support (Laurent, Guy)
svn path=/trunk/; revision=36
* PPP fixes (Gerald)
* Null/loopback interface support (Gerald)
svn path=/trunk/; revision=25