layouting the dialog buttons, and use it where appropriate.
This will help us with the GTK1/2 conflict on button layouts and
will also result in a more consistent look of the dialogs at all.
svn path=/trunk/; revision=9771
By using Find Next/Previous you will jump to the next/previous matching packet in the ethereal main window.
I could not get CTRL-N / CTRL-B to work and was too lazy to research.
It would be nice if CTRL-N / CTRL-P would invoke the same thing as selecting
/Find Frame/Find Next/EP1 <-> EP2
or
/Find Frame/Find Previous/EP1 <-> EP2
from the menu.
I could not figure out how to get gtk to do this.
The person that adds CTRL-N/CTRL-B here will be a hero.
svn path=/trunk/; revision=8635
that will open the find frame dialogue and preload the filter string
with the conversation and the direction the user selected from the menu.
svn path=/trunk/; revision=8386
so we shouldn't torment the users by offering it.
Check the string type and convert it to an internal representation in
the GUI code; have the search code deal only with the internal
representation.
Save the case-sensitivity flag, and the indication of where string
searches look, along with other search parameters.
Upper-casify the string, for case-insensitive searches, in the GUI code;
don't save the upper-casified string, so it doesn't SHOUT at you when
you next pop up a "find" dialog.
Convert the hex value string to raw binary data in the GUI code, rather
than doing so in the search code. Check that it's a valid string.
Connect the signals to the radio buttons after the pointers have been
attached to various GUI items - the signal handlers expect some of those
pointers to be attached, and aren't happy if they're not.
Have "find_packet()" contain a framework for searching, but not contain
the matching code; instead, pass it a pointer to a matching routine and
an opaque pointer to be passed to the matching routine. Have all the
routines that do different types of searching have their own matching
routines, and use the common "find_packet()" code, rather than
duplicating that code.
Search for the Info column by column type, not by name (the user can
change the name).
When matching on the protocol tree, don't format the entire protocol
tree into a big buffer - just have a routine that matches the text
representation of a protocol tree item against a string, and, if it
finds a match, sets a "we found a match flag" and returns; have that
routine not bother doing any more work if that flag is set.
(Unfortunately, you can't abort "g_node_children_foreach()" in the
middle of a traversal.)
Free the generated display filter code after a find-by-display-filter
finishes.
svn path=/trunk/; revision=8306
indicate where they apply, and give tooltips to some of the options.
Disable the "Filter:" button unless we're searching with a display filter.
Use "Frame data" instead of "Hex" for the option to search the raw frame
data, use "Decoded packet" instead of "Decode" for the option to search
the strings in the protocol tree display, and use "Packet summary"
instead of "Summary" for the option to search the Info column in the
packet list display, to make it a bit clearer what's being searched.
svn path=/trunk/; revision=8303
"destroy" signal handler for any button that pops up a filter; if the
button has a filter dialog box associated with it, it destroys that
dialog box.
Have the routines that create filter dialog boxes asociate the dialog
box with the button that created it, so that if the button is destroyed
the filter dialog box can be destroyed as well, and associate the button
with the dialog box.
This means that if a dialog box has a button to create a filter, we no
longer have to have the destroy handler for the dialog box destroy any
filters - that'll happen when the button in the dialog box is destroyed
as part of the process of destroying the dialog box.
Don't make the "Filter" buttons in the io_stat dialog box insensitive if
there's already a filter dialog box open - we can have more than one
open per dialog box.
svn path=/trunk/; revision=6930
Don't show progress bar for quick "Find Frame" searches
Add "Find Next" and "Find Previous" to repeat searches
Add documentation for "Find Next" and "Find Previous".
svn path=/trunk/; revision=5378
"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
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
selection change event on the list of filters. Unfortunately, this can
happen after some other widgets in that dialog box have already been
destroyed - including some of the widgets that such a selection change
event can change.
This sometimes happened when "filter_prefs_delete()" hadn't been called,
so the mechanism we had been using, with a Boolean datum attached to the
dialog box, set in "filter_prefs_delete()" before we actually destroy
the dialog box, wasn't sufficient to keep that from happening.
Attach to the top-level window data items containing pointers to the
widgets changed when a filter is selected from the list, give each of
those widgets their own destroy callbacks, clear the pointer attached to
the top-level widget when the widget is destroyed, and don't do anything
to the widget when a filter is selected from the list if the pointer for
that widget is null, as that means the widget's been destroyed and we
*can't* do anything to it.
Not all filter editing dialogs created on behalf of a "Filter:" button
next to a text entry box should, when you click "OK", activate the text
entry box; if the text entry box is part of a dialog box with multiple
widgets, the user might not have filled in all of the items in that
dialog box, so you shouldn't activate it for them. Add a mechanism by
which, when creating a filter editing dialog box, you can specify
whether the "OK" button should just fill in the text entry box or should
fill it in and also activate it.
svn path=/trunk/; revision=2922
display tree, based on Jeff Foster's dialog box for selecting fields.
Make the dialog box for browsing filters into a dialog box for
constructing filters; make the "Apply" button and the "OK" button apply
the filter in the text entry box in the dialog, not the currently
selected filter (selecting a filter puts it in that text entry box, but
the user may edit it afterwards, or may use the aforementioned dialog
box to construct a filter not in the list).
Get rid of extra declarations of "m_r_font" and "m_b_font" in
"proto_draw.c"; they're declared in "gtk/gtkglobals.h", which it includes.
svn path=/trunk/; revision=2805
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
- 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
to use "warning" dialog boxes only to warn the user "if you do that, bad
things may happen" *and* to offer them the option either to drive on or
quit, so perhaps ESD_TYPE_CRIT should be used for all errors).
However, put "Ethereal: Error" rather than "Ethereal: Critical" in the
title bar, in the hopes that it'll make it clearer that Something Bad
Happened.
If the user specifies that captures should be saved to a user-specified
file rather than a temporary file, report errors trying to create that
file with "file_open_error_message()".
Make the "for_writing" argument to "file_open_error_message()" a
"gboolean", as it's either TRUE (if the file is being opened for
writing) or FALSE (if it's being opened for reading).
Report EISDIR as "XXX is a directory (folder), not a file.".
svn path=/trunk/; revision=2143
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
make it easier to use grep to find all references to it without getting
a lot of false hits and to check, after allocating the memory chunk for
"frame_data" structures, that the allocation succeeded.
svn path=/trunk/; revision=2092
set the "activate" signal for a widget to call a routine to
activate the "OK" button for a dialog box;
set the "key_press_event" signal for a top-level dialog window
to call a routine to activate the "Cancel" button for a dialog
box if the key being pressed is the <Esc> key;
to make it easier to drive dialog boxes entirely from the keyboard.
Make the "Find Frame" and "Go To Frame" dialog boxes use those
utilities.
svn path=/trunk/; revision=1903
"global" dialog box when "Edit:Filters" is selected, so that the list of
filters can be edited, and "filter_browse_cb()", which pops up a dialog
box associated with a "Filter:" button and a text entry widget attached
to that button, so that a filter can be selected or saved (although it
also supports the same editing that the "global" dialog box does).
Have "filter_dialog_cb()" connect the window in which the "Filter:"
button lives and the filter dialog box, so that:
if the window in which the "Filter:" button lives goes away, so
does the filter dialog box (as it no longer has a text widget
into which it can stuff the selected filter);
if the "Filter:" button is clicked when there's already a filter
dialog box open, we just reactivate that existing dialog box
rather than popping up a new one.
Also keep a pointer to the "global" filter dialog box, so that we also
arrange that there's only one of them (by reactivating the existing on
if "Edit:Filters" is selected when there's already a "global" filter
dialog box open).
Keep around pointers to the dialog boxes that contain the "Filter:"
buttons, so that we can arrange that there be only one of them (that was
a side-effect of an earlier attempt at fixing the problems described
above, but it's still useful for keeping multiple competing dialog boxes
from being open - there's more of that to be done).
Make the pointer to the "Open Capture File" dialog box widget static to
"file_dlg.c" - nobody outside of "file_dlg.c cares about it.
svn path=/trunk/; revision=1774
Declare the one routine exported by "gtk/filter_prefs.c" in
"gtk/filter_prefs.h" rather than in "gtk/main.h". Declare
"E_FILT_TE_PTR_KEY" there, as well, rather than in "prefs_dlg.h", as the
filter-editing dialog box is no longer a preference tab.
Don't include "prefs_dlg.h" unless the stuff declared therein is of
interest.
Fix "gtk/find_dlg.c" to fire up the filter-editing dialog box, not the
no-longer-extant preferences tab for filters, if the "Filter:" button is
clicked.
svn path=/trunk/; revision=1619
into "gtk/ui_util.c", and move the declarations of those UI utilities
out of "util.h" into "ui_util.h". (The header file is in the top-level
directory, rather than the "gtk" directory, because it declares
window-system-independent interfaces to routines with
window-system-dependent implementations.)
Add to "gtk/ui_util.c" a routine to set the window and icon title.
Use that routine to make the title of an Ethereal top-level window be
{filename} - Ethereal
if there's a capture open, and have "{filename}" be "<capture>" if it's
a temporary capture file.
svn path=/trunk/; revision=1255
filter to search forward or backward in the list of displayed frames for
a matching frame.
When filtering the display, readjust the display to show the "current"
frame if it passed the display filter. When a file is read in, the
first frame becomes the "current" frame; when a frame is selected, it
becomes the "current" frame, and remains so *even if you unselect it*,
until another frame is selected.
Select the first frame when a file is read in.
Disable most of the "Display" and "Tools" menu items if there's no
current capture file, and enable the relevant ones if there is.
svn path=/trunk/; revision=982
Ulf Lamping