aboutsummaryrefslogtreecommitdiffstats
path: root/gtk/filter_prefs.h
AgeCommit message (Collapse)AuthorFilesLines
2004-01-25add syntax check and an "Add Expression" button to the filter toolbarUlf Lamping1-3/+7
svn path=/trunk/; revision=9839
2004-01-18no more differences, wether display filter dialog is called fromUlf Lamping1-1/+2
menu "Analyze->Display Filter" or statusbar "Filter:" button. svn path=/trunk/; revision=9698
2003-01-15Move the code that associates buttons with filter dialogs, and viceGuy Harris1-4/+3
versa, into "filter_dialog_new()", rather than replicating it in a couple of routines. The return value of "display_filter_construct_cb()" isn't used for anything, it's ignored by most callers and stored but subsequently ignored by io_stat.c; get rid of the return value, and don't bother storing it in io_stat.c. Before destroying a filter dialog box associated with a button being destroyed, break the association. Get rid of an unused variable in io_stat.c. svn path=/trunk/; revision=6931
2003-01-15Add a new routine "filter_button_destroy_cb()", and make it theGuy Harris1-3/+2
"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
2003-01-11From Ronald Henderson, when closing IO-Stat window, also close any open ↵Ronnie Sahlberg1-2/+2
Filter dialogs svn path=/trunk/; revision=6916
2002-08-28Removed trailing whitespaces from .h and .c files using theJörg Mayer1-4/+4
winapi_cleanup tool written by Patrik Stridvall for the wine project. svn path=/trunk/; revision=6117
2001-02-23The text entry box that a filter construction dialog manipulates isGuy Harris1-2/+1
always attached to the dialog as the E_FILT_FILTER_TE_KEY data, but only sometimes attached as the E_FILT_TE_KEY data. Get rid of E_FILT_TE_KEY completely, as it's redundant, and use only E_FILT_FILTER_TE_KEY; this keeps us from crashing as a result of trying to manipulate the widget referred to by E_FILT_TE_KEY if E_FILT_TE_KEY hasn't been set to refer to any widget. svn path=/trunk/; revision=3067
2001-01-28Have separate capture and display filter lists; some filter dialog boxesGuy Harris1-2/+3
use the capture filter lists, and others use the display filter list, as appropriate. Have separate menu items for editing the capture and display filter lists. Have separate "~/.ethereal/cfilters" and "~/.ethereal/dfilters" files for the two lists; if either of those files isn't found, we try "~/.ethereal/filters", which means that you will start out with two identical lists holding all your filters - if certain filters belong only in one list, you'll have to delete them by hand from the other list. Do I/O error checking when reading and writing filter lists; when writing a filter list, write it to a new file, and then rename the new file on top of the old file, so that you don't lose your old filter list if, for example, you run out of disk space or disk quota. svn path=/trunk/; revision=2948
2001-01-21Give various filter constructing/editing dialog boxes titles to reflectGuy Harris1-1/+2
what they were popped up for. svn path=/trunk/; revision=2923
2001-01-21In the process of destroying a filter editing dialog box, we get aGuy Harris1-2/+12
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
2001-01-02Add a dialog box for constructing expressions that test a field in theGuy Harris1-2/+4
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
2000-08-05Arrange that filter dialog boxes have an "Apply" button only if one canGuy Harris1-2/+2
apply the filter, i.e. only if the dialog box is attached to the filter text entry in the main window. svn path=/trunk/; revision=2212
2000-04-01Split "filter_dialog_cb()" into "filter_dialog_cb()", which pops up aGuy Harris1-2/+5
"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
2000-02-12Make the routines internal to the filter-editing dialog box static.Guy Harris1-12/+7
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
1999-09-10We need to catch a "window delete" event for the preferences dialog boxGuy Harris1-1/+2
- 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
1999-09-09Put RCS IDs (and a copyright notice and GPL notice) in several files,Guy Harris1-3/+3
and fix up the introductory comment on some other files. svn path=/trunk/; revision=640
1999-09-09I forgot to include this file move in my last commit.Gilbert Ramirez1-0/+39
svn path=/trunk/; revision=637