osmith
/
wireshark
forked from osmocom/wireshark
1
0
Fork 0
Code Pull Requests Releases Wiki Activity
wireshark/gtk/filter_prefs.c

1178 lines
38 KiB
C
Raw Normal View History

Put RCS IDs (and a copyright notice and GPL notice) in several files, and fix up the introductory comment on some other files. svn path=/trunk/; revision=640
1999-09-09 04:25:49 +00:00
/* filter_prefs.c
Change the comments to reflect the fact that this is now no longer a tab of the "Edit:Preferences" dialog box. svn path=/trunk/; revision=1279
1999-12-10 07:20:57 +00:00
* Dialog boxes for filter editing
* (This used to be a notebook page under "Preferences", hence the
* "prefs" in the file name.)
Initial revision svn path=/trunk/; revision=2
1998-09-16 02:39:15 +00:00
*
From Devin Heitmueller: give the user a warning if they click "New" in the filter list editing code without having specified a filter name and string. svn path=/trunk/; revision=5737
2002-06-22 20:00:26 +00:00
* $Id: filter_prefs.c,v 1.37 2002/06/22 20:00:26 guy Exp $
Added ID tags to the beginning of each source file. svn path=/trunk/; revision=7
1998-09-16 03:22:19 +00:00
*
Initial revision svn path=/trunk/; revision=2
1998-09-16 02:39:15 +00:00
* Ethereal - Network traffic analyzer
Add a new routine to create the ".ethereal" directory for a user. Use that routine rather than duplicating that code in the routines to write out the preference file and filter files. Use it in the code for the color filter dialog, so that the directory in question is created if necessary. As that routine returns an error indication, have the code that calls that routine put up a message box if the attempt fails. svn path=/trunk/; revision=4065
2001-10-23 05:01:02 +00:00
* By Gerald Combs <gerald@ethereal.com>
Initial revision svn path=/trunk/; revision=2
1998-09-16 02:39:15 +00:00
* Copyright 1998 Gerald Combs
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*/
#ifdef HAVE_CONFIG_H
# include "config.h"
#endif
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
#include <string.h>
Initial revision svn path=/trunk/; revision=2
1998-09-16 02:39:15 +00:00
#include <gtk/gtk.h>
Add a new routine to create the ".ethereal" directory for a user. Use that routine rather than duplicating that code in the routines to write out the preference file and filter files. Use it in the code for the color filter dialog, so that the directory in question is created if necessary. As that routine returns an error indication, have the code that calls that routine put up a message box if the attempt fails. svn path=/trunk/; revision=4065
2001-10-23 05:01:02 +00:00
#include <epan/filesystem.h>
Pull the stuff to read and write the list of filter expressions up into a file in the top-level directory. svn path=/trunk/; revision=2946
2001-01-28 04:43:26 +00:00
#include "filters.h"
More shuffling of GTK-related files to gtk subdirectory. svn path=/trunk/; revision=635
1999-09-09 02:42:40 +00:00
#include "gtk/main.h"
I forgot to include this file move in my last commit. svn path=/trunk/; revision=637
1999-09-09 03:35:32 +00:00
#include "filter_prefs.h"
Add a "dlg_window_new()" routine, which creates a GTK_WINDOW_DIALOG 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
2000-07-05 02:45:42 +00:00
#include "dlg_utils.h"
Split "filter_dialog_cb()" into "filter_dialog_cb()", which pops up a "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-04-01 12:03:42 +00:00
#include "ui_util.h"
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
#include "simple_dialog.h"
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
#include "dfilter_expr_dlg.h"
Initial revision svn path=/trunk/; revision=2
1998-09-16 02:39:15 +00:00
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
#define E_FILT_PARENT_FILTER_TE_KEY "filter_parent_filter_te"
#define E_FILT_CONSTRUCT_ARGS_KEY "filter_construct_args"
Arrange that if the filter list is edited in one dialog box, the filter lists in all filter dialog boxes are updated to reflect reality. (The poor man's model-view.) svn path=/trunk/; revision=2924
2001-01-21 03:30:24 +00:00
#define E_FILT_LIST_ITEM_MODEL_KEY "filter_list_item_model"
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
#define E_FILT_LBL_KEY "filter_label"
#define E_FILT_FILTER_L_KEY "filter_filter_l"
#define E_FILT_CHG_BT_KEY "filter_chg_bt"
#define E_FILT_COPY_BT_KEY "filter_copy_bt"
#define E_FILT_DEL_BT_KEY "filter_del_bt"
#define E_FILT_NAME_TE_KEY "filter_name_te"
#define E_FILT_FILTER_TE_KEY "filter_filter_te"
#define E_FILT_DBLFUNC_KEY "filter_dblfunc"
#define E_FILT_DBLARG_KEY "filter_dblarg"
A double-click in a filter name in the list-of-filters dialog box should activate the text widget into which the filter text is put only if clicking "OK" in the list-of-filters dialog box does so. Make it so. svn path=/trunk/; revision=4955
2002-03-16 22:02:55 +00:00
#define E_FILT_DBLACTIVATE_KEY "filter_dblactivate"
* Pod page update * Minor tweaks to the filter prefs svn path=/trunk/; revision=40
1998-10-13 02:10:57 +00:00
I forgot to include this file move in my last commit. svn path=/trunk/; revision=637
1999-09-09 03:35:32 +00:00
typedef struct _filter_cb_data {
GList *fl;
GtkWidget *win;
} filter_cb_data;
Arrange that filter dialog boxes have an "Apply" button only if one can 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-08-05 07:02:28 +00:00
static GtkWidget *filter_dialog_new(GtkWidget *caller, GtkWidget *filter_te,
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
filter_list_type_t list, construct_args_t *construct_args);
A double-click in a filter name in the list-of-filters dialog box should activate the text widget into which the filter text is put only if clicking "OK" in the list-of-filters dialog box does so. Make it so. svn path=/trunk/; revision=4955
2002-03-16 22:02:55 +00:00
static void filter_dlg_dclick(GtkWidget *dummy, gpointer main_w_arg,
gpointer activate);
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
static void filter_dlg_ok_cb(GtkWidget *ok_bt, gpointer dummy);
static void filter_dlg_apply_cb(GtkWidget *apply_bt, gpointer dummy);
Remove some no-longer-applicable XXX comments. When you click "OK" on the dialog box, destroy the dialog box *before* activating any text widget into which we've stuffed the filter expression, so we don't get the dialog box destroyed out from under us before we try to destroy it ourselves. svn path=/trunk/; revision=5367
2002-05-02 23:49:21 +00:00
static void filter_apply(GtkWidget *main_w, gboolean destroy);
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
static void filter_dlg_save_cb(GtkWidget *save_bt, gpointer parent_w);
Use "Close", rather than "Cancel", in the filter dialog box; clicking that button doesn't undo edits you've made to the list of filters it's displaying. Don't show an "OK" button if the dialog isn't attached to a text entry box, as the "OK" button means "enter the current filter into the attached text entry box, and close the dialog", and if there *is* no attached text entry box, "OK" doesn't do what you might expect (it's equivalent to "Close"). svn path=/trunk/; revision=2952
2001-01-28 21:30:53 +00:00
static void filter_dlg_close_cb(GtkWidget *close_bt, gpointer parent_w);
Split "filter_dialog_cb()" into "filter_dialog_cb()", which pops up a "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-04-01 12:03:42 +00:00
static void filter_dlg_destroy(GtkWidget *win, gpointer data);
* Pod page update * Minor tweaks to the filter prefs svn path=/trunk/; revision=40
1998-10-13 02:10:57 +00:00
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
static gint filter_sel_list_button_cb(GtkWidget *, GdkEventButton *,
gpointer);
Make the routines internal to the filter-editing dialog box static. 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
2000-02-12 06:46:54 +00:00
static void filter_sel_list_cb(GtkWidget *, gpointer);
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
static void filter_list_destroy_cb(GtkWidget *, gpointer);
Arrange that if the filter list is edited in one dialog box, the filter lists in all filter dialog boxes are updated to reflect reality. (The poor man's model-view.) svn path=/trunk/; revision=2924
2001-01-21 03:30:24 +00:00
static void filter_new_bt_clicked_cb(GtkWidget *, gpointer);
static void filter_chg_bt_clicked_cb(GtkWidget *, gpointer);
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
static void filter_chg_bt_destroy_cb(GtkWidget *, gpointer);
Arrange that if the filter list is edited in one dialog box, the filter lists in all filter dialog boxes are updated to reflect reality. (The poor man's model-view.) svn path=/trunk/; revision=2924
2001-01-21 03:30:24 +00:00
static void filter_copy_bt_clicked_cb(GtkWidget *, gpointer);
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
static void filter_copy_bt_destroy_cb(GtkWidget *, gpointer);
Arrange that if the filter list is edited in one dialog box, the filter lists in all filter dialog boxes are updated to reflect reality. (The poor man's model-view.) svn path=/trunk/; revision=2924
2001-01-21 03:30:24 +00:00
static void filter_del_bt_clicked_cb(GtkWidget *, gpointer);
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
static void filter_del_bt_destroy_cb(GtkWidget *, gpointer);
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
static void filter_expr_cb(GtkWidget *, gpointer);
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
static void filter_name_te_destroy_cb(GtkWidget *, gpointer);
static void filter_filter_te_destroy_cb(GtkWidget *, gpointer);
Make the routines internal to the filter-editing dialog box static. 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
2000-02-12 06:46:54 +00:00
Don't offer the ability to edit capture filters if Ethereal wasn't linked with libpcap. svn path=/trunk/; revision=3613
2001-06-27 10:00:14 +00:00
#ifdef HAVE_LIBPCAP
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
/* Create a filter dialog for constructing a capture filter.
This is to be used as a callback for a button next to a text entry box,
which, when clicked, pops up this dialog to allow you to construct a
display filter by browsing the list of saved filters (the dialog
for constructing expressions assumes display filter syntax, not
capture filter syntax). The "OK" button sets the text entry box to the
constructed filter and activates that text entry box (which should have
Remove some no-longer-applicable XXX comments. When you click "OK" on the dialog box, destroy the dialog box *before* activating any text widget into which we've stuffed the filter expression, so we don't get the dialog box destroyed out from under us before we try to destroy it ourselves. svn path=/trunk/; revision=5367
2002-05-02 23:49:21 +00:00
no effect in the main capture dialog); this dialog is then dismissed. */
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
void
From Joerg Mayer: use _U_ to flag unused arguments. svn path=/trunk/; revision=4878
2002-03-05 11:56:00 +00:00
capture_filter_construct_cb(GtkWidget *w, gpointer user_data _U_)
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
{
GtkWidget *caller = gtk_widget_get_toplevel(w);
GtkWidget *filter_browse_w;
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
GtkWidget *parent_filter_te;
/* No Apply button, and "OK" just sets our text widget, it doesn't
activate it (i.e., it doesn't cause us to try to open the file). */
Give various filter constructing/editing dialog boxes titles to reflect what they were popped up for. svn path=/trunk/; revision=2923
2001-01-21 02:27:24 +00:00
static construct_args_t args = {
"Ethereal: Capture Filter",
FALSE,
FALSE
};
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
/* Has a filter dialog box already been opened for that top-level
widget? */
filter_browse_w = gtk_object_get_data(GTK_OBJECT(caller),
E_FILT_DIALOG_PTR_KEY);
if (filter_browse_w != NULL) {
/* Yes. Just re-activate that dialog box. */
reactivate_window(filter_browse_w);
return;
}
/* No. Get the text entry attached to the button. */
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
parent_filter_te = gtk_object_get_data(GTK_OBJECT(w), E_FILT_TE_PTR_KEY);
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
/* Now create a new dialog, without an "Add Expression..." button. */
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
filter_browse_w = filter_dialog_new(caller, parent_filter_te,
CFILTER_LIST, &args);
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
/* Set the E_FILT_CALLER_PTR_KEY for the new dialog to point to
our caller. */
gtk_object_set_data(GTK_OBJECT(filter_browse_w), E_FILT_CALLER_PTR_KEY,
caller);
/* Set the E_FILT_DIALOG_PTR_KEY for the caller to point to us */
gtk_object_set_data(GTK_OBJECT(caller), E_FILT_DIALOG_PTR_KEY,
filter_browse_w);
}
Don't offer the ability to edit capture filters if Ethereal wasn't linked with libpcap. svn path=/trunk/; revision=3613
2001-06-27 10:00:14 +00:00
#endif
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
/* Create a filter dialog for constructing a display filter.
This is to be used as a callback for a button next to a text entry box,
which, when clicked, pops up this dialog to allow you to construct a
display filter by browsing the list of saved filters and/or by adding
test expressions constructed with another dialog. The "OK" button
sets the text entry box to the constructed filter and activates that
text entry box, causing the filter to be used; this dialog is then
dismissed.
If "wants_apply_button" is non-null, we add an "Apply" button that
Remove some no-longer-applicable XXX comments. When you click "OK" on the dialog box, destroy the dialog box *before* activating any text widget into which we've stuffed the filter expression, so we don't get the dialog box destroyed out from under us before we try to destroy it ourselves. svn path=/trunk/; revision=5367
2002-05-02 23:49:21 +00:00
acts like "OK" but doesn't dismiss this dialog. */
Split "filter_dialog_cb()" into "filter_dialog_cb()", which pops up a "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-04-01 12:03:42 +00:00
void
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
display_filter_construct_cb(GtkWidget *w, gpointer construct_args_ptr)
Split "filter_dialog_cb()" into "filter_dialog_cb()", which pops up a "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-04-01 12:03:42 +00:00
{
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
construct_args_t *construct_args = construct_args_ptr;
Split "filter_dialog_cb()" into "filter_dialog_cb()", which pops up a "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-04-01 12:03:42 +00:00
GtkWidget *caller = gtk_widget_get_toplevel(w);
GtkWidget *filter_browse_w;
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
GtkWidget *parent_filter_te;
Split "filter_dialog_cb()" into "filter_dialog_cb()", which pops up a "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-04-01 12:03:42 +00:00
/* Has a filter dialog box already been opened for that top-level
widget? */
filter_browse_w = gtk_object_get_data(GTK_OBJECT(caller),
E_FILT_DIALOG_PTR_KEY);
if (filter_browse_w != NULL) {
/* Yes. Just re-activate that dialog box. */
reactivate_window(filter_browse_w);
return;
}
/* No. Get the text entry attached to the button. */
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
parent_filter_te = gtk_object_get_data(GTK_OBJECT(w), E_FILT_TE_PTR_KEY);
Split "filter_dialog_cb()" into "filter_dialog_cb()", which pops up a "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-04-01 12:03:42 +00:00
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
/* Now create a new dialog, possibly with an "Apply" button, and
definitely with an "Add Expression..." button. */
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
filter_browse_w = filter_dialog_new(caller, parent_filter_te,
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
DFILTER_LIST, construct_args);
Split "filter_dialog_cb()" into "filter_dialog_cb()", which pops up a "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-04-01 12:03:42 +00:00
/* Set the E_FILT_CALLER_PTR_KEY for the new dialog to point to
our caller. */
gtk_object_set_data(GTK_OBJECT(filter_browse_w), E_FILT_CALLER_PTR_KEY,
caller);
/* Set the E_FILT_DIALOG_PTR_KEY for the caller to point to us */
gtk_object_set_data(GTK_OBJECT(caller), E_FILT_DIALOG_PTR_KEY,
filter_browse_w);
}
Don't offer the ability to edit capture filters if Ethereal wasn't linked with libpcap. svn path=/trunk/; revision=3613
2001-06-27 10:00:14 +00:00
#ifdef HAVE_LIBPCAP
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
static GtkWidget *global_cfilter_w;
/* Create a filter dialog for editing capture filters; this is to be used
as a callback for menu items, toolbars, etc.. */
void
From Joerg Mayer: use _U_ to flag unused arguments. svn path=/trunk/; revision=4878
2002-03-05 11:56:00 +00:00
cfilter_dialog_cb(GtkWidget *w _U_)
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
{
/* No Apply button, and there's no text widget to set, much less
activate, on "OK". */
static construct_args_t args = {
"Ethereal: Edit Capture Filter List",
FALSE,
FALSE
};
/* Has a filter dialog box already been opened for editing
capture filters? */
if (global_cfilter_w != NULL) {
/* Yes. Just reactivate it. */
reactivate_window(global_cfilter_w);
return;
}
/*
* No. Create one; we didn't pop this up as a result of pressing
* a button next to some text entry field, so don't associate it
* with a text entry field.
*/
global_cfilter_w = filter_dialog_new(NULL, NULL, CFILTER_LIST, &args);
}
Don't offer the ability to edit capture filters if Ethereal wasn't linked with libpcap. svn path=/trunk/; revision=3613
2001-06-27 10:00:14 +00:00
#endif
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
static GtkWidget *global_dfilter_w;
Split "filter_dialog_cb()" into "filter_dialog_cb()", which pops up a "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-04-01 12:03:42 +00:00
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
/* Create a filter dialog for editing display filters; this is to be used
as a callback for menu items, toolbars, etc.. */
Jerry Talkington's patch to remove the filter stuff from "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
1999-12-10 06:28:24 +00:00
void
From Joerg Mayer: use _U_ to flag unused arguments. svn path=/trunk/; revision=4878
2002-03-05 11:56:00 +00:00
dfilter_dialog_cb(GtkWidget *w _U_)
Split "filter_dialog_cb()" into "filter_dialog_cb()", which pops up a "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-04-01 12:03:42 +00:00
{
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
/* No Apply button, and there's no text widget to set, much less
activate, on "OK". */
Give various filter constructing/editing dialog boxes titles to reflect what they were popped up for. svn path=/trunk/; revision=2923
2001-01-21 02:27:24 +00:00
static construct_args_t args = {
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
"Ethereal: Edit Display Filter List",
Give various filter constructing/editing dialog boxes titles to reflect what they were popped up for. svn path=/trunk/; revision=2923
2001-01-21 02:27:24 +00:00
FALSE,
FALSE
};
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
/* Has a filter dialog box already been opened for editing
display filters? */
if (global_dfilter_w != NULL) {
Split "filter_dialog_cb()" into "filter_dialog_cb()", which pops up a "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-04-01 12:03:42 +00:00
/* Yes. Just reactivate it. */
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
reactivate_window(global_dfilter_w);
Split "filter_dialog_cb()" into "filter_dialog_cb()", which pops up a "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-04-01 12:03:42 +00:00
return;
}
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
/*
* No. Create one; we didn't pop this up as a result of pressing
* a button next to some text entry field, so don't associate it
* with a text entry field.
*/
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
global_dfilter_w = filter_dialog_new(NULL, NULL, DFILTER_LIST, &args);
Split "filter_dialog_cb()" into "filter_dialog_cb()", which pops up a "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-04-01 12:03:42 +00:00
}
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
/* List of capture filter dialogs, so that if the list of filters changes
(the model, if you will), we can update all of their lists displaying
the filters (the views). */
static GList *cfilter_dialogs;
/* List of display filter dialogs, so that if the list of filters changes
(the model, if you will), we can update all of their lists displaying
Arrange that if the filter list is edited in one dialog box, the filter lists in all filter dialog boxes are updated to reflect reality. (The poor man's model-view.) svn path=/trunk/; revision=2924
2001-01-21 03:30:24 +00:00
the filters (the views). */
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
static GList *dfilter_dialogs;
Arrange that if the filter list is edited in one dialog box, the filter lists in all filter dialog boxes are updated to reflect reality. (The poor man's model-view.) svn path=/trunk/; revision=2924
2001-01-21 03:30:24 +00:00
static void
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
remember_filter_dialog(GtkWidget *main_w, GList **filter_dialogs)
Arrange that if the filter list is edited in one dialog box, the filter lists in all filter dialog boxes are updated to reflect reality. (The poor man's model-view.) svn path=/trunk/; revision=2924
2001-01-21 03:30:24 +00:00
{
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
*filter_dialogs = g_list_append(*filter_dialogs, main_w);
Arrange that if the filter list is edited in one dialog box, the filter lists in all filter dialog boxes are updated to reflect reality. (The poor man's model-view.) svn path=/trunk/; revision=2924
2001-01-21 03:30:24 +00:00
}
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
/* Remove a filter dialog from the specified list of filter_dialogs. */
Arrange that if the filter list is edited in one dialog box, the filter lists in all filter dialog boxes are updated to reflect reality. (The poor man's model-view.) svn path=/trunk/; revision=2924
2001-01-21 03:30:24 +00:00
static void
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
forget_filter_dialog(GtkWidget *main_w, filter_list_type_t list)
{
switch (list) {
case CFILTER_LIST:
cfilter_dialogs = g_list_remove(cfilter_dialogs, main_w);
break;
case DFILTER_LIST:
dfilter_dialogs = g_list_remove(dfilter_dialogs, main_w);
break;
default:
g_assert_not_reached();
break;
}
}
/* Get the dialog list corresponding to a particular filter list. */
static GList *
get_filter_dialog_list(filter_list_type_t list)
Arrange that if the filter list is edited in one dialog box, the filter lists in all filter dialog boxes are updated to reflect reality. (The poor man's model-view.) svn path=/trunk/; revision=2924
2001-01-21 03:30:24 +00:00
{
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
switch (list) {
case CFILTER_LIST:
return cfilter_dialogs;
case DFILTER_LIST:
return dfilter_dialogs;
default:
g_assert_not_reached();
return NULL;
}
Arrange that if the filter list is edited in one dialog box, the filter lists in all filter dialog boxes are updated to reflect reality. (The poor man's model-view.) svn path=/trunk/; revision=2924
2001-01-21 03:30:24 +00:00
}
Split "filter_dialog_cb()" into "filter_dialog_cb()", which pops up a "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-04-01 12:03:42 +00:00
static GtkWidget *
From Joerg Mayer: use _U_ to flag unused arguments. svn path=/trunk/; revision=4878
2002-03-05 11:56:00 +00:00
filter_dialog_new(GtkWidget *caller _U_, GtkWidget *parent_filter_te,
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
filter_list_type_t list, construct_args_t *construct_args)
Jerry Talkington's patch to remove the filter stuff from "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
1999-12-10 06:28:24 +00:00
{
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
GtkWidget *main_w, /* main window */
*main_vb, /* main container */
*bbox, /* button container */
*ok_bt, /* "OK" button */
*apply_bt, /* "Apply" button */
*save_bt, /* "Save" button */
Use "Close", rather than "Cancel", in the filter dialog box; clicking that button doesn't undo edits you've made to the list of filters it's displaying. Don't show an "OK" button if the dialog isn't attached to a text entry box, as the "OK" button means "enter the current filter into the attached text entry box, and close the dialog", and if there *is* no attached text entry box, "OK" doesn't do what you might expect (it's equivalent to "Close"). svn path=/trunk/; revision=2952
2001-01-28 21:30:53 +00:00
*close_bt; /* "Cancel" button */
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
GtkWidget *filter_pg = NULL; /* filter settings box */
GtkWidget *top_hb,
*list_bb,
*new_bt,
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
*chg_bt,
*copy_bt,
*del_bt,
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
*filter_sc,
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
*filter_l,
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
*nl_item,
*nl_lb,
*middle_hb,
*name_lb,
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
*name_te,
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
*bottom_hb,
*filter_lb,
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
*filter_te,
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
*add_expression_bt;
GtkWidget *l_select = NULL;
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
GList *fl_entry;
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
filter_def *filt;
gchar *filter_te_str = NULL;
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
GList **filter_dialogs;
static filter_list_type_t cfilter_list = CFILTER_LIST;
static filter_list_type_t dfilter_list = DFILTER_LIST;
filter_list_type_t *filter_list_p;
/* Get a pointer to a static variable holding the type of filter on
which we're working, so we can pass that pointer to callback
routines. */
switch (list) {
case CFILTER_LIST:
filter_dialogs = &cfilter_dialogs;
filter_list_p = &cfilter_list;
break;
case DFILTER_LIST:
filter_dialogs = &dfilter_dialogs;
filter_list_p = &dfilter_list;
break;
default:
g_assert_not_reached();
filter_dialogs = NULL;
filter_list_p = NULL;
break;
}
Jerry Talkington's patch to remove the filter stuff from "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
1999-12-10 06:28:24 +00:00
Give various filter constructing/editing dialog boxes titles to reflect what they were popped up for. svn path=/trunk/; revision=2923
2001-01-21 02:27:24 +00:00
main_w = dlg_window_new(construct_args->title);
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
gtk_object_set_data(GTK_OBJECT(main_w), E_FILT_CONSTRUCT_ARGS_KEY,
construct_args);
Jerry Talkington's patch to remove the filter stuff from "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
1999-12-10 06:28:24 +00:00
Split "filter_dialog_cb()" into "filter_dialog_cb()", which pops up a "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-04-01 12:03:42 +00:00
/* Call a handler when we're destroyed, so we can inform
our caller, if any, that we've been destroyed. */
gtk_signal_connect(GTK_OBJECT(main_w), "destroy",
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
GTK_SIGNAL_FUNC(filter_dlg_destroy), filter_list_p);
Split "filter_dialog_cb()" into "filter_dialog_cb()", which pops up a "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-04-01 12:03:42 +00:00
Jerry Talkington's patch to remove the filter stuff from "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
1999-12-10 06:28:24 +00:00
main_vb = gtk_vbox_new(FALSE, 5);
gtk_container_border_width(GTK_CONTAINER(main_vb), 5);
gtk_container_add(GTK_CONTAINER(main_w), main_vb);
gtk_widget_show(main_vb);
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
/* Make sure everything is set up */
if (parent_filter_te)
filter_te_str = gtk_entry_get_text(GTK_ENTRY(parent_filter_te));
/* Container for each row of widgets */
filter_pg = gtk_vbox_new(FALSE, 5);
gtk_container_border_width(GTK_CONTAINER(filter_pg), 5);
gtk_widget_show(filter_pg);
/* Top row: Filter list and buttons */
top_hb = gtk_hbox_new(FALSE, 5);
gtk_container_add(GTK_CONTAINER(filter_pg), top_hb);
gtk_widget_show(top_hb);
list_bb = gtk_vbutton_box_new();
gtk_button_box_set_layout (GTK_BUTTON_BOX (list_bb), GTK_BUTTONBOX_START);
gtk_container_add(GTK_CONTAINER(top_hb), list_bb);
gtk_widget_show(list_bb);
new_bt = gtk_button_new_with_label ("New");
gtk_signal_connect(GTK_OBJECT(new_bt), "clicked",
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
GTK_SIGNAL_FUNC(filter_new_bt_clicked_cb), filter_list_p);
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
gtk_container_add(GTK_CONTAINER(list_bb), new_bt);
gtk_widget_show(new_bt);
chg_bt = gtk_button_new_with_label ("Change");
gtk_widget_set_sensitive(chg_bt, FALSE);
gtk_signal_connect(GTK_OBJECT(chg_bt), "clicked",
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
GTK_SIGNAL_FUNC(filter_chg_bt_clicked_cb), filter_list_p);
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
gtk_object_set_data(GTK_OBJECT(main_w), E_FILT_CHG_BT_KEY, chg_bt);
gtk_signal_connect(GTK_OBJECT(chg_bt), "destroy",
GTK_SIGNAL_FUNC(filter_chg_bt_destroy_cb), NULL);
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
gtk_container_add(GTK_CONTAINER(list_bb), chg_bt);
gtk_widget_show(chg_bt);
copy_bt = gtk_button_new_with_label ("Copy");
gtk_widget_set_sensitive(copy_bt, FALSE);
gtk_signal_connect(GTK_OBJECT(copy_bt), "clicked",
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
GTK_SIGNAL_FUNC(filter_copy_bt_clicked_cb), filter_list_p);
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
gtk_object_set_data(GTK_OBJECT(main_w), E_FILT_COPY_BT_KEY, copy_bt);
gtk_signal_connect(GTK_OBJECT(copy_bt), "destroy",
GTK_SIGNAL_FUNC(filter_copy_bt_destroy_cb), NULL);
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
gtk_container_add(GTK_CONTAINER(list_bb), copy_bt);
gtk_widget_show(copy_bt);
del_bt = gtk_button_new_with_label ("Delete");
gtk_widget_set_sensitive(del_bt, FALSE);
gtk_signal_connect(GTK_OBJECT(del_bt), "clicked",
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
GTK_SIGNAL_FUNC(filter_del_bt_clicked_cb), filter_list_p);
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
gtk_object_set_data(GTK_OBJECT(main_w), E_FILT_DEL_BT_KEY, del_bt);
gtk_signal_connect(GTK_OBJECT(del_bt), "destroy",
GTK_SIGNAL_FUNC(filter_del_bt_destroy_cb), NULL);
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
gtk_container_add(GTK_CONTAINER(list_bb), del_bt);
gtk_widget_show(del_bt);
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
if (list == DFILTER_LIST) {
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
/* Create the "Add Expression..." button, to pop up a dialog
for constructing filter comparison expressions. */
add_expression_bt = gtk_button_new_with_label("Add Expression...");
gtk_signal_connect(GTK_OBJECT(add_expression_bt), "clicked",
GTK_SIGNAL_FUNC(filter_expr_cb), main_w);
gtk_container_add(GTK_CONTAINER(list_bb), add_expression_bt);
gtk_widget_show(add_expression_bt);
}
filter_sc = gtk_scrolled_window_new(NULL, NULL);
gtk_scrolled_window_set_policy(GTK_SCROLLED_WINDOW(filter_sc),
GTK_POLICY_AUTOMATIC, GTK_POLICY_AUTOMATIC);
gtk_widget_set_usize(filter_sc, 250, 150);
gtk_container_add(GTK_CONTAINER(top_hb), filter_sc);
gtk_widget_show(filter_sc);
filter_l = gtk_list_new();
gtk_list_set_selection_mode(GTK_LIST(filter_l), GTK_SELECTION_SINGLE);
gtk_signal_connect(GTK_OBJECT(filter_l), "selection_changed",
GTK_SIGNAL_FUNC(filter_sel_list_cb), filter_pg);
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
gtk_object_set_data(GTK_OBJECT(main_w), E_FILT_FILTER_L_KEY, filter_l);
gtk_signal_connect(GTK_OBJECT(filter_l), "destroy",
GTK_SIGNAL_FUNC(filter_list_destroy_cb), NULL);
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
gtk_scrolled_window_add_with_viewport(GTK_SCROLLED_WINDOW(filter_sc),
filter_l);
gtk_widget_show(filter_l);
gtk_object_set_data(GTK_OBJECT(filter_l), E_FILT_DBLFUNC_KEY, filter_dlg_dclick);
gtk_object_set_data(GTK_OBJECT(filter_l), E_FILT_DBLARG_KEY, main_w);
A double-click in a filter name in the list-of-filters dialog box should activate the text widget into which the filter text is put only if clicking "OK" in the list-of-filters dialog box does so. Make it so. svn path=/trunk/; revision=4955
2002-03-16 22:02:55 +00:00
/* This is a Boolean, but we make it a non-null pointer for TRUE
and a null pointer for FALSE, as object data is a pointer. */
gtk_object_set_data(GTK_OBJECT(filter_l), E_FILT_DBLACTIVATE_KEY,
construct_args->activate_on_ok? "" : NULL);
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
fl_entry = get_filter_list_first(list);
while (fl_entry != NULL) {
filt = (filter_def *) fl_entry->data;
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
nl_lb = gtk_label_new(filt->name);
nl_item = gtk_list_item_new();
gtk_signal_connect(GTK_OBJECT(nl_item), "button_press_event",
GTK_SIGNAL_FUNC(filter_sel_list_button_cb), filter_l);
gtk_misc_set_alignment (GTK_MISC (nl_lb), 0.0, 0.5);
gtk_container_add(GTK_CONTAINER(nl_item), nl_lb);
gtk_widget_show(nl_lb);
gtk_container_add(GTK_CONTAINER(filter_l), nl_item);
gtk_widget_show(nl_item);
gtk_object_set_data(GTK_OBJECT(nl_item), E_FILT_LBL_KEY, nl_lb);
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
gtk_object_set_data(GTK_OBJECT(nl_item), E_FILT_LIST_ITEM_MODEL_KEY,
fl_entry);
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
if (filter_te_str && filt->strval) {
if (strcmp(filter_te_str, filt->strval) == 0)
l_select = nl_item;
}
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
fl_entry = fl_entry->next;
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
}
/* Middle row: Filter name entry */
middle_hb = gtk_hbox_new(FALSE, 5);
gtk_container_add(GTK_CONTAINER(filter_pg), middle_hb);
gtk_widget_show(middle_hb);
name_lb = gtk_label_new("Filter name:");
gtk_box_pack_start(GTK_BOX(middle_hb), name_lb, FALSE, FALSE, 3);
gtk_widget_show(name_lb);
name_te = gtk_entry_new();
gtk_box_pack_start(GTK_BOX(middle_hb), name_te, TRUE, TRUE, 3);
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
gtk_object_set_data(GTK_OBJECT(main_w), E_FILT_NAME_TE_KEY, name_te);
gtk_signal_connect(GTK_OBJECT(name_te), "destroy",
GTK_SIGNAL_FUNC(filter_name_te_destroy_cb), NULL);
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
gtk_widget_show(name_te);
/* Bottom row: Filter text entry */
bottom_hb = gtk_hbox_new(FALSE, 5);
gtk_container_add(GTK_CONTAINER(filter_pg), bottom_hb);
gtk_widget_show(bottom_hb);
filter_lb = gtk_label_new("Filter string:");
gtk_box_pack_start(GTK_BOX(bottom_hb), filter_lb, FALSE, FALSE, 3);
gtk_widget_show(filter_lb);
filter_te = gtk_entry_new();
gtk_box_pack_start(GTK_BOX(bottom_hb), filter_te, TRUE, TRUE, 3);
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
gtk_object_set_data(GTK_OBJECT(main_w), E_FILT_FILTER_TE_KEY, filter_te);
The text entry box that a filter construction dialog manipulates is 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-02-23 05:54:27 +00:00
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
gtk_signal_connect(GTK_OBJECT(filter_te), "destroy",
GTK_SIGNAL_FUNC(filter_filter_te_destroy_cb), NULL);
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
gtk_widget_show(filter_te);
if (l_select) {
gtk_list_select_child(GTK_LIST(filter_l), l_select);
} else if (filter_te_str && filter_te_str[0]) {
gtk_entry_set_text(GTK_ENTRY(name_te), "New filter");
gtk_entry_set_text(GTK_ENTRY(filter_te), filter_te_str);
}
Jerry Talkington's patch to remove the filter stuff from "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
1999-12-10 06:28:24 +00:00
gtk_box_pack_start(GTK_BOX(main_vb), filter_pg, TRUE, TRUE, 0);
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
gtk_object_set_data(GTK_OBJECT(main_w), E_FILT_PARENT_FILTER_TE_KEY,
parent_filter_te);
Jerry Talkington's patch to remove the filter stuff from "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
1999-12-10 06:28:24 +00:00
bbox = gtk_hbutton_box_new();
gtk_button_box_set_layout (GTK_BUTTON_BOX (bbox), GTK_BUTTONBOX_END);
gtk_button_box_set_spacing(GTK_BUTTON_BOX(bbox), 5);
gtk_container_add(GTK_CONTAINER(main_vb), bbox);
gtk_widget_show(bbox);
Use "Close", rather than "Cancel", in the filter dialog box; clicking that button doesn't undo edits you've made to the list of filters it's displaying. Don't show an "OK" button if the dialog isn't attached to a text entry box, as the "OK" button means "enter the current filter into the attached text entry box, and close the dialog", and if there *is* no attached text entry box, "OK" doesn't do what you might expect (it's equivalent to "Close"). svn path=/trunk/; revision=2952
2001-01-28 21:30:53 +00:00
if (parent_filter_te != NULL) {
/*
* We have a filter text entry that we can fill in if
* the "OK" button is clicked, so put in an "OK" button.
*/
ok_bt = gtk_button_new_with_label ("OK");
gtk_signal_connect(GTK_OBJECT(ok_bt), "clicked",
GTK_SIGNAL_FUNC(filter_dlg_ok_cb), NULL);
GTK_WIDGET_SET_FLAGS(ok_bt, GTK_CAN_DEFAULT);
gtk_box_pack_start(GTK_BOX(bbox), ok_bt, TRUE, TRUE, 0);
gtk_widget_grab_default(ok_bt);
gtk_widget_show(ok_bt);
Make the "activate" signal on the text entry boxes in the filter editing dialog activate the entire dialog box. svn path=/trunk/; revision=3062
2001-02-20 20:25:08 +00:00
/* Catch the "activate" signal on the filter name and filter
expression text entries, so that if the user types Return
there, we act as if the "OK" button had been selected, as
happens if Return is typed if some widget that *doesn't*
handle the Return key has the input focus. */
dlg_set_activate(name_te, ok_bt);
dlg_set_activate(filter_te, ok_bt);
Use "Close", rather than "Cancel", in the filter dialog box; clicking that button doesn't undo edits you've made to the list of filters it's displaying. Don't show an "OK" button if the dialog isn't attached to a text entry box, as the "OK" button means "enter the current filter into the attached text entry box, and close the dialog", and if there *is* no attached text entry box, "OK" doesn't do what you might expect (it's equivalent to "Close"). svn path=/trunk/; revision=2952
2001-01-28 21:30:53 +00:00
}
Jerry Talkington's patch to remove the filter stuff from "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
1999-12-10 06:28:24 +00:00
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
if (construct_args->wants_apply_button) {
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
apply_bt = gtk_button_new_with_label ("Apply");
gtk_signal_connect(GTK_OBJECT(apply_bt), "clicked",
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
GTK_SIGNAL_FUNC(filter_dlg_apply_cb), NULL);
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
GTK_WIDGET_SET_FLAGS(apply_bt, GTK_CAN_DEFAULT);
gtk_box_pack_start(GTK_BOX(bbox), apply_bt, TRUE, TRUE, 0);
gtk_widget_show(apply_bt);
}
Jerry Talkington's patch to remove the filter stuff from "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
1999-12-10 06:28:24 +00:00
save_bt = gtk_button_new_with_label ("Save");
gtk_signal_connect(GTK_OBJECT(save_bt), "clicked",
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
GTK_SIGNAL_FUNC(filter_dlg_save_cb), filter_list_p);
Jerry Talkington's patch to remove the filter stuff from "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
1999-12-10 06:28:24 +00:00
GTK_WIDGET_SET_FLAGS(save_bt, GTK_CAN_DEFAULT);
gtk_box_pack_start(GTK_BOX(bbox), save_bt, TRUE, TRUE, 0);
gtk_widget_show(save_bt);
Use "Close", rather than "Cancel", in the filter dialog box; clicking that button doesn't undo edits you've made to the list of filters it's displaying. Don't show an "OK" button if the dialog isn't attached to a text entry box, as the "OK" button means "enter the current filter into the attached text entry box, and close the dialog", and if there *is* no attached text entry box, "OK" doesn't do what you might expect (it's equivalent to "Close"). svn path=/trunk/; revision=2952
2001-01-28 21:30:53 +00:00
close_bt = gtk_button_new_with_label ("Close");
gtk_signal_connect(GTK_OBJECT(close_bt), "clicked",
GTK_SIGNAL_FUNC(filter_dlg_close_cb), GTK_OBJECT(main_w));
GTK_WIDGET_SET_FLAGS(close_bt, GTK_CAN_DEFAULT);
gtk_box_pack_start(GTK_BOX(bbox), close_bt, TRUE, TRUE, 0);
gtk_widget_show(close_bt);
Jerry Talkington's patch to remove the filter stuff from "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
1999-12-10 06:28:24 +00:00
Make the "activate" signal on the text entry boxes in the filter editing dialog activate the entire dialog box. svn path=/trunk/; revision=3062
2001-02-20 20:25:08 +00:00
/*
* Catch the "key_press_event" signal in the window, so that we can
* catch the ESC key being pressed and act as if the "Close" button
* had been selected.
*/
Use "Close", rather than "Cancel", in the filter dialog box; clicking that button doesn't undo edits you've made to the list of filters it's displaying. Don't show an "OK" button if the dialog isn't attached to a text entry box, as the "OK" button means "enter the current filter into the attached text entry box, and close the dialog", and if there *is* no attached text entry box, "OK" doesn't do what you might expect (it's equivalent to "Close"). svn path=/trunk/; revision=2952
2001-01-28 21:30:53 +00:00
dlg_set_cancel(main_w, close_bt);
This patch adds two things: - Pressing Esc key will cause the filter selection dialog to "Cancel" - Double-clicking on a list item in filter selection dialog is equivalent to single-click followed by "OK" Santeri Paavolainen <santtu@ssh.com> svn path=/trunk/; revision=2533
2000-10-25 16:06:50 +00:00
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
remember_filter_dialog(main_w, filter_dialogs);
Arrange that if the filter list is edited in one dialog box, the filter lists in all filter dialog boxes are updated to reflect reality. (The poor man's model-view.) svn path=/trunk/; revision=2924
2001-01-21 03:30:24 +00:00
Jerry Talkington's patch to remove the filter stuff from "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
1999-12-10 06:28:24 +00:00
gtk_widget_show(main_w);
Split "filter_dialog_cb()" into "filter_dialog_cb()", which pops up a "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-04-01 12:03:42 +00:00
return main_w;
Jerry Talkington's patch to remove the filter stuff from "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
1999-12-10 06:28:24 +00:00
}
static void
A double-click in a filter name in the list-of-filters dialog box should activate the text widget into which the filter text is put only if clicking "OK" in the list-of-filters dialog box does so. Make it so. svn path=/trunk/; revision=4955
2002-03-16 22:02:55 +00:00
filter_dlg_dclick(GtkWidget *filter_l, gpointer main_w_arg, gpointer activate)
Jerry Talkington's patch to remove the filter stuff from "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
1999-12-10 06:28:24 +00:00
{
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
GtkWidget *main_w = GTK_WIDGET(main_w_arg);
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
GtkWidget *parent_filter_te =
gtk_object_get_data(GTK_OBJECT(main_w), E_FILT_PARENT_FILTER_TE_KEY);
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
GList *flp, *sl;
GtkObject *l_item;
filter_def *filt;
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
if (parent_filter_te != NULL) {
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
/*
* We have a text entry widget associated with this dialog
* box; is one of the filters in the list selected?
*/
sl = GTK_LIST(filter_l)->selection;
if (sl != NULL) {
/*
A double-click in a filter name in the list-of-filters dialog box should activate the text widget into which the filter text is put only if clicking "OK" in the list-of-filters dialog box does so. Make it so. svn path=/trunk/; revision=4955
2002-03-16 22:02:55 +00:00
* Yes. Is there a filter definition for that filter?
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
*/
l_item = GTK_OBJECT(sl->data);
Arrange that if the filter list is edited in one dialog box, the filter lists in all filter dialog boxes are updated to reflect reality. (The poor man's model-view.) svn path=/trunk/; revision=2924
2001-01-21 03:30:24 +00:00
flp = (GList *) gtk_object_get_data(l_item, E_FILT_LIST_ITEM_MODEL_KEY);
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
if (flp) {
A double-click in a filter name in the list-of-filters dialog box should activate the text widget into which the filter text is put only if clicking "OK" in the list-of-filters dialog box does so. Make it so. svn path=/trunk/; revision=4955
2002-03-16 22:02:55 +00:00
/*
* Yes - put it in the text entry widget.
*/
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
filt = (filter_def *) flp->data;
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
gtk_entry_set_text(GTK_ENTRY(parent_filter_te),
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
filt->strval);
A double-click in a filter name in the list-of-filters dialog box should activate the text widget into which the filter text is put only if clicking "OK" in the list-of-filters dialog box does so. Make it so. svn path=/trunk/; revision=4955
2002-03-16 22:02:55 +00:00
/*
* Are we supposed to cause the filter we
* put there to be applied?
*/
if (activate != NULL) {
/*
* Yes - do so.
*/
gtk_signal_emit_by_name(GTK_OBJECT(parent_filter_te),
"activate");
}
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
}
}
}
gtk_widget_destroy(main_w);
Jerry Talkington's patch to remove the filter stuff from "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
1999-12-10 06:28:24 +00:00
}
Initial revision svn path=/trunk/; revision=2
1998-09-16 02:39:15 +00:00
Jerry Talkington's patch to remove the filter stuff from "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
1999-12-10 06:28:24 +00:00
static void
From Joerg Mayer: use _U_ to flag unused arguments. svn path=/trunk/; revision=4878
2002-03-05 11:56:00 +00:00
filter_dlg_ok_cb(GtkWidget *ok_bt, gpointer data _U_)
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
{
/*
Remove some no-longer-applicable XXX comments. When you click "OK" on the dialog box, destroy the dialog box *before* activating any text widget into which we've stuffed the filter expression, so we don't get the dialog box destroyed out from under us before we try to destroy it ourselves. svn path=/trunk/; revision=5367
2002-05-02 23:49:21 +00:00
* Destroy the dialog box and apply the filter.
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
*/
Remove some no-longer-applicable XXX comments. When you click "OK" on the dialog box, destroy the dialog box *before* activating any text widget into which we've stuffed the filter expression, so we don't get the dialog box destroyed out from under us before we try to destroy it ourselves. svn path=/trunk/; revision=5367
2002-05-02 23:49:21 +00:00
filter_apply(gtk_widget_get_toplevel(ok_bt), TRUE);
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
}
static void
From Joerg Mayer: use _U_ to flag unused arguments. svn path=/trunk/; revision=4878
2002-03-05 11:56:00 +00:00
filter_dlg_apply_cb(GtkWidget *apply_bt, gpointer dummy _U_)
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
{
Remove some no-longer-applicable XXX comments. When you click "OK" on the dialog box, destroy the dialog box *before* activating any text widget into which we've stuffed the filter expression, so we don't get the dialog box destroyed out from under us before we try to destroy it ourselves. svn path=/trunk/; revision=5367
2002-05-02 23:49:21 +00:00
/*
* Apply the filter, but don't destroy the dialog box.
*/
filter_apply(gtk_widget_get_toplevel(apply_bt), FALSE);
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
}
static void
Remove some no-longer-applicable XXX comments. When you click "OK" on the dialog box, destroy the dialog box *before* activating any text widget into which we've stuffed the filter expression, so we don't get the dialog box destroyed out from under us before we try to destroy it ourselves. svn path=/trunk/; revision=5367
2002-05-02 23:49:21 +00:00
filter_apply(GtkWidget *main_w, gboolean destroy)
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
{
construct_args_t *construct_args =
gtk_object_get_data(GTK_OBJECT(main_w), E_FILT_CONSTRUCT_ARGS_KEY);
GtkWidget *parent_filter_te =
gtk_object_get_data(GTK_OBJECT(main_w), E_FILT_PARENT_FILTER_TE_KEY);
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
GtkWidget *filter_te;
gchar *filter_string;
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
if (parent_filter_te != NULL) {
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
/*
* We have a text entry widget associated with this dialog
* box; put the filter in our text entry widget into that
Remove some no-longer-applicable XXX comments. When you click "OK" on the dialog box, destroy the dialog box *before* activating any text widget into which we've stuffed the filter expression, so we don't get the dialog box destroyed out from under us before we try to destroy it ourselves. svn path=/trunk/; revision=5367
2002-05-02 23:49:21 +00:00
* text entry widget.
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
*/
filter_te = gtk_object_get_data(GTK_OBJECT(main_w),
The text entry box that a filter construction dialog manipulates is 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-02-23 05:54:27 +00:00
E_FILT_FILTER_TE_KEY);
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
filter_string = gtk_entry_get_text(GTK_ENTRY(filter_te));
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
gtk_entry_set_text(GTK_ENTRY(parent_filter_te), filter_string);
Remove some no-longer-applicable XXX comments. When you click "OK" on the dialog box, destroy the dialog box *before* activating any text widget into which we've stuffed the filter expression, so we don't get the dialog box destroyed out from under us before we try to destroy it ourselves. svn path=/trunk/; revision=5367
2002-05-02 23:49:21 +00:00
}
if (destroy) {
/*
* Destroy the filter dialog box.
*/
gtk_widget_destroy(main_w);
}
if (parent_filter_te != NULL) {
/*
* We have a text entry widget associated with this dialog
* box; activate that widget to cause the filter we put
* there to be applied if we're supposed to do so.
*
* We do this after dismissing the filter dialog box,
* as activating the widget the dialog box to which
* it belongs to be dismissed, and that may cause it
* to destroy our dialog box if the filter succeeds.
* This means that our subsequent attempt to destroy
* it will fail.
*
* We don't know whether it'll destroy our dialog box,
* so we can't rely on it to do so. Instead, we
* destroy it ourselves, which will clear the
* E_FILT_DIALOG_PTR_KEY pointer for their dialog box,
* meaning they won't think it has one and won't try
* to destroy it.
*/
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
if (construct_args->activate_on_ok) {
gtk_signal_emit_by_name(GTK_OBJECT(parent_filter_te),
"activate");
}
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
}
}
static void
From Joerg Mayer: use _U_ to flag unused arguments. svn path=/trunk/; revision=4878
2002-03-05 11:56:00 +00:00
filter_dlg_save_cb(GtkWidget *save_bt _U_, gpointer data)
Jerry Talkington's patch to remove the filter stuff from "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
1999-12-10 06:28:24 +00:00
{
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
filter_list_type_t list = *(filter_list_type_t *)data;
On Windows, put Ethereal configuration files under the "Application Data\Ethereal" directory under the user's profile, as that appears to be the Windows 2000 standard. svn path=/trunk/; revision=4071
2001-10-24 06:13:07 +00:00
char *pf_dir_path;
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
char *f_path;
int f_save_errno;
char *filter_type;
Add a new routine to create the ".ethereal" directory for a user. Use that routine rather than duplicating that code in the routines to write out the preference file and filter files. Use it in the code for the color filter dialog, so that the directory in question is created if necessary. As that routine returns an error indication, have the code that calls that routine put up a message box if the attempt fails. svn path=/trunk/; revision=4065
2001-10-23 05:01:02 +00:00
/* Create the directory that holds personal configuration files,
if necessary. */
if (create_persconffile_dir(&pf_dir_path) == -1) {
simple_dialog(ESD_TYPE_WARN, NULL,
"Can't create directory\n\"%s\"\nfor filter files: %s.",
pf_dir_path, strerror(errno));
On Windows, put Ethereal configuration files under the "Application Data\Ethereal" directory under the user's profile, as that appears to be the Windows 2000 standard. svn path=/trunk/; revision=4071
2001-10-24 06:13:07 +00:00
g_free(pf_dir_path);
Add a new routine to create the ".ethereal" directory for a user. Use that routine rather than duplicating that code in the routines to write out the preference file and filter files. Use it in the code for the color filter dialog, so that the directory in question is created if necessary. As that routine returns an error indication, have the code that calls that routine put up a message box if the attempt fails. svn path=/trunk/; revision=4065
2001-10-23 05:01:02 +00:00
return;
}
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
save_filter_list(list, &f_path, &f_save_errno);
if (f_path != NULL) {
/* We had an error saving the filter. */
switch (list) {
case CFILTER_LIST:
filter_type = "capture";
break;
case DFILTER_LIST:
filter_type = "display";
break;
default:
g_assert_not_reached();
filter_type = NULL;
break;
}
simple_dialog(ESD_TYPE_CRIT, NULL,
"Could not save to your %s filter file\n\"%s\": %s.",
filter_type, f_path, strerror(f_save_errno));
g_free(f_path);
}
Jerry Talkington's patch to remove the filter stuff from "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
1999-12-10 06:28:24 +00:00
}
static void
From Joerg Mayer: use _U_ to flag unused arguments. svn path=/trunk/; revision=4878
2002-03-05 11:56:00 +00:00
filter_dlg_close_cb(GtkWidget *close_bt _U_, gpointer parent_w)
Jerry Talkington's patch to remove the filter stuff from "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
1999-12-10 06:28:24 +00:00
{
gtk_widget_destroy(GTK_WIDGET(parent_w));
}
Split "filter_dialog_cb()" into "filter_dialog_cb()", which pops up a "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-04-01 12:03:42 +00:00
static void
filter_dlg_destroy(GtkWidget *win, gpointer data)
{
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
filter_list_type_t list = *(filter_list_type_t *)data;
Split "filter_dialog_cb()" into "filter_dialog_cb()", which pops up a "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-04-01 12:03:42 +00:00
GtkWidget *caller;
/* Get the widget that requested that we be popped up, if any.
(It should arrange to destroy us if it's destroyed, so
that we don't get a pointer to a non-existent window here.) */
caller = gtk_object_get_data(GTK_OBJECT(win), E_FILT_CALLER_PTR_KEY);
if (caller != NULL) {
/* Tell it we no longer exist. */
gtk_object_set_data(GTK_OBJECT(caller), E_FILT_DIALOG_PTR_KEY,
NULL);
} else {
/* This is an editing dialog popped up from, for example,
a menu item; note that we no longer have one. */
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
switch (list) {
Don't offer the ability to edit capture filters if Ethereal wasn't linked with libpcap. svn path=/trunk/; revision=3613
2001-06-27 10:00:14 +00:00
#ifdef HAVE_LIBPCAP
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
case CFILTER_LIST:
g_assert(win == global_cfilter_w);
global_cfilter_w = NULL;
break;
Don't offer the ability to edit capture filters if Ethereal wasn't linked with libpcap. svn path=/trunk/; revision=3613
2001-06-27 10:00:14 +00:00
#endif
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
case DFILTER_LIST:
g_assert(win == global_dfilter_w);
global_dfilter_w = NULL;
break;
default:
g_assert_not_reached();
break;
}
Split "filter_dialog_cb()" into "filter_dialog_cb()", which pops up a "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-04-01 12:03:42 +00:00
}
Arrange that if the filter list is edited in one dialog box, the filter lists in all filter dialog boxes are updated to reflect reality. (The poor man's model-view.) svn path=/trunk/; revision=2924
2001-01-21 03:30:24 +00:00
/* Remove this from the list of filter dialog windows. */
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
forget_filter_dialog(win, list);
Arrange that if the filter list is edited in one dialog box, the filter lists in all filter dialog boxes are updated to reflect reality. (The poor man's model-view.) svn path=/trunk/; revision=2924
2001-01-21 03:30:24 +00:00
Split "filter_dialog_cb()" into "filter_dialog_cb()", which pops up a "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-04-01 12:03:42 +00:00
/* Now nuke this window. */
gtk_grab_remove(GTK_WIDGET(win));
gtk_widget_destroy(GTK_WIDGET(win));
}
This patch adds two things: - Pressing Esc key will cause the filter selection dialog to "Cancel" - Double-clicking on a list item in filter selection dialog is equivalent to single-click followed by "OK" Santeri Paavolainen <santtu@ssh.com> svn path=/trunk/; revision=2533
2000-10-25 16:06:50 +00:00
static gint
filter_sel_list_button_cb (GtkWidget *widget, GdkEventButton *event,
gpointer func_data)
{
GtkWidget *parent = func_data;
GtkSignalFunc func;
gpointer func_arg;
A double-click in a filter name in the list-of-filters dialog box should activate the text widget into which the filter text is put only if clicking "OK" in the list-of-filters dialog box does so. Make it so. svn path=/trunk/; revision=4955
2002-03-16 22:02:55 +00:00
gpointer func_activate;
This patch adds two things: - Pressing Esc key will cause the filter selection dialog to "Cancel" - Double-clicking on a list item in filter selection dialog is equivalent to single-click followed by "OK" Santeri Paavolainen <santtu@ssh.com> svn path=/trunk/; revision=2533
2000-10-25 16:06:50 +00:00
if (GTK_IS_LIST_ITEM(widget) && event->type == GDK_2BUTTON_PRESS) {
func = gtk_object_get_data(GTK_OBJECT(parent), E_FILT_DBLFUNC_KEY);
func_arg = gtk_object_get_data(GTK_OBJECT(parent), E_FILT_DBLARG_KEY);
A double-click in a filter name in the list-of-filters dialog box should activate the text widget into which the filter text is put only if clicking "OK" in the list-of-filters dialog box does so. Make it so. svn path=/trunk/; revision=4955
2002-03-16 22:02:55 +00:00
func_activate = gtk_object_get_data(GTK_OBJECT(parent), E_FILT_DBLACTIVATE_KEY);
This patch adds two things: - Pressing Esc key will cause the filter selection dialog to "Cancel" - Double-clicking on a list item in filter selection dialog is equivalent to single-click followed by "OK" Santeri Paavolainen <santtu@ssh.com> svn path=/trunk/; revision=2533
2000-10-25 16:06:50 +00:00
if (func)
A double-click in a filter name in the list-of-filters dialog box should activate the text widget into which the filter text is put only if clicking "OK" in the list-of-filters dialog box does so. Make it so. svn path=/trunk/; revision=4955
2002-03-16 22:02:55 +00:00
(*func)(func_data, func_arg, func_activate);
This patch adds two things: - Pressing Esc key will cause the filter selection dialog to "Cancel" - Double-clicking on a list item in filter selection dialog is equivalent to single-click followed by "OK" Santeri Paavolainen <santtu@ssh.com> svn path=/trunk/; revision=2533
2000-10-25 16:06:50 +00:00
}
return FALSE;
}
Make the routines internal to the filter-editing dialog box static. 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
2000-02-12 06:46:54 +00:00
static void
From Joerg Mayer: use _U_ to flag unused arguments. svn path=/trunk/; revision=4878
2002-03-05 11:56:00 +00:00
filter_sel_list_cb(GtkWidget *l, gpointer data _U_)
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
{
GtkWidget *main_w = gtk_widget_get_toplevel(l);
GtkWidget *name_te = gtk_object_get_data(GTK_OBJECT(main_w), E_FILT_NAME_TE_KEY);
GtkWidget *filter_te = gtk_object_get_data(GTK_OBJECT(main_w), E_FILT_FILTER_TE_KEY);
GtkWidget *chg_bt = gtk_object_get_data(GTK_OBJECT(main_w), E_FILT_CHG_BT_KEY);
GtkWidget *copy_bt = gtk_object_get_data(GTK_OBJECT(main_w), E_FILT_COPY_BT_KEY);
GtkWidget *del_bt = gtk_object_get_data(GTK_OBJECT(main_w), E_FILT_DEL_BT_KEY);
Initial revision svn path=/trunk/; revision=2
1998-09-16 02:39:15 +00:00
filter_def *filt;
gchar *name = "", *strval = "";
GList *sl, *flp;
GtkObject *l_item;
gint sensitivity = FALSE;
Fixed more bugs with dialogues and gtk+-1.1.x. svn path=/trunk/; revision=137
1998-12-22 07:07:11 +00:00
if (l)
sl = GTK_LIST(l)->selection;
else
sl = NULL;
Initial revision svn path=/trunk/; revision=2
1998-09-16 02:39:15 +00:00
if (sl) { /* Something was selected */
l_item = GTK_OBJECT(sl->data);
Arrange that if the filter list is edited in one dialog box, the filter lists in all filter dialog boxes are updated to reflect reality. (The poor man's model-view.) svn path=/trunk/; revision=2924
2001-01-21 03:30:24 +00:00
flp = (GList *) gtk_object_get_data(l_item, E_FILT_LIST_ITEM_MODEL_KEY);
Initial revision svn path=/trunk/; revision=2
1998-09-16 02:39:15 +00:00
if (flp) {
filt = (filter_def *) flp->data;
name = filt->name;
strval = filt->strval;
sensitivity = TRUE;
}
}
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
/*
* Did you know that this function is called when the window is destroyed?
* Funny, that.
* This means that we have to:
*
* attach to the top-level window data items containing pointers to
* the widgets we affect here;
*
* give each of those widgets their own destroy callbacks;
*
* clear that pointer when the widget is destroyed;
*
* don't do anything to the widget if the pointer we get back is
* null;
*
* so that if we're called after any of the widgets we'd affect are
* destroyed, we know that we shouldn't do anything to those widgets.
*/
if (name_te != NULL)
Initial revision svn path=/trunk/; revision=2
1998-09-16 02:39:15 +00:00
gtk_entry_set_text(GTK_ENTRY(name_te), name);
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
if (filter_te != NULL)
Initial revision svn path=/trunk/; revision=2
1998-09-16 02:39:15 +00:00
gtk_entry_set_text(GTK_ENTRY(filter_te), strval);
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
if (chg_bt != NULL)
Initial revision svn path=/trunk/; revision=2
1998-09-16 02:39:15 +00:00
gtk_widget_set_sensitive(chg_bt, sensitivity);
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
if (copy_bt != NULL)
Initial revision svn path=/trunk/; revision=2
1998-09-16 02:39:15 +00:00
gtk_widget_set_sensitive(copy_bt, sensitivity);
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
if (del_bt != NULL)
Initial revision svn path=/trunk/; revision=2
1998-09-16 02:39:15 +00:00
gtk_widget_set_sensitive(del_bt, sensitivity);
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
}
static void
From Joerg Mayer: use _U_ to flag unused arguments. svn path=/trunk/; revision=4878
2002-03-05 11:56:00 +00:00
filter_list_destroy_cb(GtkWidget *l, gpointer data _U_)
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
{
GtkWidget *main_w = gtk_widget_get_toplevel(l);
gtk_object_set_data(GTK_OBJECT(main_w), E_FILT_FILTER_L_KEY, NULL);
Initial revision svn path=/trunk/; revision=2
1998-09-16 02:39:15 +00:00
}
/* To do: add input checking to each of these callbacks */
Arrange that if the filter list is edited in one dialog box, the filter lists in all filter dialog boxes are updated to reflect reality. (The poor man's model-view.) svn path=/trunk/; revision=2924
2001-01-21 03:30:24 +00:00
/* Structure containing arguments to be passed to "new_filter_cb()".
"active_filter_l" is the list in the dialog box in which "New" or
"Copy" was clicked; in that dialog box, but not in any other dialog
box, we select the newly created list item.
"nflp" is the GList member in the model (filter list) for the new
filter. */
typedef struct {
GtkWidget *active_filter_l;
GList *nflp;
} new_filter_cb_args_t;
static void
new_filter_cb(gpointer data, gpointer user_data)
{
GtkWidget *main_w = data;
GtkWidget *filter_l = gtk_object_get_data(GTK_OBJECT(main_w), E_FILT_FILTER_L_KEY);
new_filter_cb_args_t *args = user_data;
filter_def *nfilt = args->nflp->data;
GtkWidget *nl_lb, *nl_item;
nl_lb = gtk_label_new(nfilt->name);
nl_item = gtk_list_item_new();
gtk_misc_set_alignment(GTK_MISC(nl_lb), 0.0, 0.5);
gtk_container_add(GTK_CONTAINER(nl_item), nl_lb);
gtk_widget_show(nl_lb);
gtk_container_add(GTK_CONTAINER(filter_l), nl_item);
gtk_widget_show(nl_item);
gtk_object_set_data(GTK_OBJECT(nl_item), E_FILT_LBL_KEY, nl_lb);
gtk_object_set_data(GTK_OBJECT(nl_item), E_FILT_LIST_ITEM_MODEL_KEY,
args->nflp);
if (filter_l == args->active_filter_l) {
/* Select the item. */
gtk_list_select_child(GTK_LIST(filter_l), nl_item);
}
}
Make the routines internal to the filter-editing dialog box static. 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
2000-02-12 06:46:54 +00:00
static void
Arrange that if the filter list is edited in one dialog box, the filter lists in all filter dialog boxes are updated to reflect reality. (The poor man's model-view.) svn path=/trunk/; revision=2924
2001-01-21 03:30:24 +00:00
filter_new_bt_clicked_cb(GtkWidget *w, gpointer data)
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
{
GtkWidget *main_w = gtk_widget_get_toplevel(w);
GtkWidget *name_te = gtk_object_get_data(GTK_OBJECT(main_w), E_FILT_NAME_TE_KEY);
GtkWidget *filter_te = gtk_object_get_data(GTK_OBJECT(main_w), E_FILT_FILTER_TE_KEY);
GtkWidget *filter_l = gtk_object_get_data(GTK_OBJECT(main_w), E_FILT_FILTER_L_KEY);
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
filter_list_type_t list = *(filter_list_type_t *)data;
GList *fl_entry;
Initial revision svn path=/trunk/; revision=2
1998-09-16 02:39:15 +00:00
gchar *name, *strval;
Arrange that if the filter list is edited in one dialog box, the filter lists in all filter dialog boxes are updated to reflect reality. (The poor man's model-view.) svn path=/trunk/; revision=2924
2001-01-21 03:30:24 +00:00
new_filter_cb_args_t args;
Initial revision svn path=/trunk/; revision=2
1998-09-16 02:39:15 +00:00
name = gtk_entry_get_text(GTK_ENTRY(name_te));
strval = gtk_entry_get_text(GTK_ENTRY(filter_te));
if (strlen(name) > 0 && strlen(strval) > 0) {
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
/* Add a new entry to the filter list. */
fl_entry = add_to_filter_list(list, name, strval);
Arrange that if the filter list is edited in one dialog box, the filter lists in all filter dialog boxes are updated to reflect reality. (The poor man's model-view.) svn path=/trunk/; revision=2924
2001-01-21 03:30:24 +00:00
/* Update all the filter list widgets, not just the one in
the dialog box in which we clicked on "Copy". */
args.active_filter_l = filter_l;
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
args.nflp = fl_entry;
g_list_foreach(get_filter_dialog_list(list), new_filter_cb, &args);
From Devin Heitmueller: give the user a warning if they click "New" in the filter list editing code without having specified a filter name and string. svn path=/trunk/; revision=5737
2002-06-22 20:00:26 +00:00
} else {
/* Give the user some basic directions on how to use the 'new' button */
simple_dialog(ESD_TYPE_WARN, NULL,
"You have left either the 'Filter name' or 'Filter string' field empty.\n"
"To add a new filter, enter a name for the filter, and enter the expression\n"
"for the filter or use the 'Add Expression...' button to construct an\n"
"expression, then click 'New'.");
Initial revision svn path=/trunk/; revision=2
1998-09-16 02:39:15 +00:00
}
}
Make the routines internal to the filter-editing dialog box static. 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
2000-02-12 06:46:54 +00:00
static void
Arrange that if the filter list is edited in one dialog box, the filter lists in all filter dialog boxes are updated to reflect reality. (The poor man's model-view.) svn path=/trunk/; revision=2924
2001-01-21 03:30:24 +00:00
chg_list_item_cb(GtkWidget *nl_item, gpointer data)
{
GList *flp = data;
filter_def *filt = flp->data;
GtkLabel *nl_lb =
GTK_LABEL(gtk_object_get_data(GTK_OBJECT(nl_item), E_FILT_LBL_KEY));
GList *nl_model =
gtk_object_get_data(GTK_OBJECT(nl_item), E_FILT_LIST_ITEM_MODEL_KEY);
/* Is this the GtkList item corresponding to the filter list item in
question? */
if (flp == nl_model) {
/* Yes - change the label to correspond to the new name for the filter. */
gtk_label_set(nl_lb, filt->name);
}
}
static void
chg_filter_cb(gpointer data, gpointer user_data)
{
GtkWidget *main_w = data;
GtkWidget *filter_l = gtk_object_get_data(GTK_OBJECT(main_w), E_FILT_FILTER_L_KEY);
gtk_container_foreach(GTK_CONTAINER(filter_l), chg_list_item_cb, user_data);
}
static void
filter_chg_bt_clicked_cb(GtkWidget *w, gpointer data)
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
{
GtkWidget *main_w = gtk_widget_get_toplevel(w);
GtkWidget *name_te = gtk_object_get_data(GTK_OBJECT(main_w), E_FILT_NAME_TE_KEY);
GtkWidget *filter_te = gtk_object_get_data(GTK_OBJECT(main_w), E_FILT_FILTER_TE_KEY);
GtkWidget *filter_l = gtk_object_get_data(GTK_OBJECT(main_w), E_FILT_FILTER_L_KEY);
Initial revision svn path=/trunk/; revision=2
1998-09-16 02:39:15 +00:00
filter_def *filt;
gchar *name = "", *strval = "";
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
GList *sl, *fl_entry;
Initial revision svn path=/trunk/; revision=2
1998-09-16 02:39:15 +00:00
GtkObject *l_item;
GtkLabel *nl_lb;
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
filter_list_type_t list = *(filter_list_type_t *)data;
Initial revision svn path=/trunk/; revision=2
1998-09-16 02:39:15 +00:00
sl = GTK_LIST(filter_l)->selection;
name = gtk_entry_get_text(GTK_ENTRY(name_te));
strval = gtk_entry_get_text(GTK_ENTRY(filter_te));
if (sl) { /* Something was selected */
l_item = GTK_OBJECT(sl->data);
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
fl_entry = (GList *) gtk_object_get_data(l_item, E_FILT_LIST_ITEM_MODEL_KEY);
nl_lb = (GtkLabel *) gtk_object_get_data(l_item, E_FILT_LBL_KEY);
if (fl_entry != NULL && nl_lb != NULL) {
filt = (filter_def *) fl_entry->data;
Initial revision svn path=/trunk/; revision=2
1998-09-16 02:39:15 +00:00
if (strlen(name) > 0 && strlen(strval) > 0 && filt) {
g_free(filt->name);
g_free(filt->strval);
filt->name = g_strdup(name);
filt->strval = g_strdup(strval);
Arrange that if the filter list is edited in one dialog box, the filter lists in all filter dialog boxes are updated to reflect reality. (The poor man's model-view.) svn path=/trunk/; revision=2924
2001-01-21 03:30:24 +00:00
/* Update all the filter list widgets, not just the one in
the dialog box in which we clicked on "Copy". */
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
g_list_foreach(get_filter_dialog_list(list), chg_filter_cb, fl_entry);
Initial revision svn path=/trunk/; revision=2
1998-09-16 02:39:15 +00:00
}
}
}
}
Make the routines internal to the filter-editing dialog box static. 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
2000-02-12 06:46:54 +00:00
static void
From Joerg Mayer: use _U_ to flag unused arguments. svn path=/trunk/; revision=4878
2002-03-05 11:56:00 +00:00
filter_chg_bt_destroy_cb(GtkWidget *chg_bt, gpointer data _U_)
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
{
GtkWidget *main_w = gtk_widget_get_toplevel(chg_bt);
gtk_object_set_data(GTK_OBJECT(main_w), E_FILT_CHG_BT_KEY, NULL);
}
static void
Arrange that if the filter list is edited in one dialog box, the filter lists in all filter dialog boxes are updated to reflect reality. (The poor man's model-view.) svn path=/trunk/; revision=2924
2001-01-21 03:30:24 +00:00
filter_copy_bt_clicked_cb(GtkWidget *w, gpointer data)
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
{
GtkWidget *main_w = gtk_widget_get_toplevel(w);
GtkWidget *filter_l = gtk_object_get_data(GTK_OBJECT(main_w), E_FILT_FILTER_L_KEY);
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
GList *sl, *fl_entry, *nfl_entry;
gchar *prefix = "Copy of ", *name;
Initial revision svn path=/trunk/; revision=2
1998-09-16 02:39:15 +00:00
GtkObject *l_item;
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
filter_def *filt;
filter_list_type_t list = *(filter_list_type_t *)data;
Arrange that if the filter list is edited in one dialog box, the filter lists in all filter dialog boxes are updated to reflect reality. (The poor man's model-view.) svn path=/trunk/; revision=2924
2001-01-21 03:30:24 +00:00
new_filter_cb_args_t args;
Initial revision svn path=/trunk/; revision=2
1998-09-16 02:39:15 +00:00
sl = GTK_LIST(filter_l)->selection;
if (sl) { /* Something was selected */
l_item = GTK_OBJECT(sl->data);
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
fl_entry = (GList *) gtk_object_get_data(l_item, E_FILT_LIST_ITEM_MODEL_KEY);
if (fl_entry != NULL) {
/* Add a new entry, copying the existing entry, to the filter list. */
filt = (filter_def *) fl_entry->data;
name = g_malloc(strlen(prefix) + strlen(filt->name) + 1);
sprintf(name, "%s%s", prefix, filt->name);
nfl_entry = add_to_filter_list(list, name, filt->strval);
g_free(name);
Arrange that if the filter list is edited in one dialog box, the filter lists in all filter dialog boxes are updated to reflect reality. (The poor man's model-view.) svn path=/trunk/; revision=2924
2001-01-21 03:30:24 +00:00
/* Update all the filter list widgets, not just the one in
the dialog box in which we clicked on "Copy". */
args.active_filter_l = filter_l;
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
args.nflp = nfl_entry;
g_list_foreach(get_filter_dialog_list(list), new_filter_cb, &args);
Initial revision svn path=/trunk/; revision=2
1998-09-16 02:39:15 +00:00
}
}
}
Make the routines internal to the filter-editing dialog box static. 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
2000-02-12 06:46:54 +00:00
static void
From Joerg Mayer: use _U_ to flag unused arguments. svn path=/trunk/; revision=4878
2002-03-05 11:56:00 +00:00
filter_copy_bt_destroy_cb(GtkWidget *copy_bt, gpointer data _U_)
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
{
GtkWidget *main_w = gtk_widget_get_toplevel(copy_bt);
gtk_object_set_data(GTK_OBJECT(main_w), E_FILT_COPY_BT_KEY, NULL);
Arrange that if the filter list is edited in one dialog box, the filter lists in all filter dialog boxes are updated to reflect reality. (The poor man's model-view.) svn path=/trunk/; revision=2924
2001-01-21 03:30:24 +00:00
}
static void
delete_filter_cb(gpointer data, gpointer user_data)
{
GtkWidget *main_w = data;
GtkWidget *filter_l = gtk_object_get_data(GTK_OBJECT(main_w), E_FILT_FILTER_L_KEY);
gint pos = *(gint *)user_data;
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
Arrange that if the filter list is edited in one dialog box, the filter lists in all filter dialog boxes are updated to reflect reality. (The poor man's model-view.) svn path=/trunk/; revision=2924
2001-01-21 03:30:24 +00:00
gtk_list_clear_items(GTK_LIST(filter_l), pos, pos + 1);
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
}
static void
Arrange that if the filter list is edited in one dialog box, the filter lists in all filter dialog boxes are updated to reflect reality. (The poor man's model-view.) svn path=/trunk/; revision=2924
2001-01-21 03:30:24 +00:00
filter_del_bt_clicked_cb(GtkWidget *w, gpointer data)
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
{
GtkWidget *main_w = gtk_widget_get_toplevel(w);
GtkWidget *filter_l = gtk_object_get_data(GTK_OBJECT(main_w), E_FILT_FILTER_L_KEY);
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
filter_list_type_t list = *(filter_list_type_t *)data;
GList *sl, *fl_entry;
Initial revision svn path=/trunk/; revision=2
1998-09-16 02:39:15 +00:00
GtkObject *l_item;
gint pos;
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
Initial revision svn path=/trunk/; revision=2
1998-09-16 02:39:15 +00:00
sl = GTK_LIST(filter_l)->selection;
if (sl) { /* Something was selected */
l_item = GTK_OBJECT(sl->data);
pos = gtk_list_child_position(GTK_LIST(filter_l),
GTK_WIDGET(l_item));
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
fl_entry = (GList *) gtk_object_get_data(l_item, E_FILT_LIST_ITEM_MODEL_KEY);
if (fl_entry != NULL) {
/* Remove the entry from the filter list. */
remove_from_filter_list(list, fl_entry);
Arrange that if the filter list is edited in one dialog box, the filter lists in all filter dialog boxes are updated to reflect reality. (The poor man's model-view.) svn path=/trunk/; revision=2924
2001-01-21 03:30:24 +00:00
/* Update all the filter list widgets, not just the one in
the dialog box in which we clicked on "Delete". */
Have separate capture and display filter lists; some filter dialog boxes 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-28 09:13:10 +00:00
g_list_foreach(get_filter_dialog_list(list), delete_filter_cb, &pos);
Initial revision svn path=/trunk/; revision=2
1998-09-16 02:39:15 +00:00
}
}
}
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
static void
From Joerg Mayer: use _U_ to flag unused arguments. svn path=/trunk/; revision=4878
2002-03-05 11:56:00 +00:00
filter_del_bt_destroy_cb(GtkWidget *del_bt, gpointer data _U_)
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
{
GtkWidget *main_w = gtk_widget_get_toplevel(del_bt);
gtk_object_set_data(GTK_OBJECT(main_w), E_FILT_DEL_BT_KEY, NULL);
}
Make the routines internal to the filter-editing dialog box static. 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
2000-02-12 06:46:54 +00:00
static void
From Joerg Mayer: use _U_ to flag unused arguments. svn path=/trunk/; revision=4878
2002-03-05 11:56:00 +00:00
filter_expr_cb(GtkWidget *w _U_, gpointer main_w_arg)
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
{
GtkWidget *main_w = GTK_WIDGET(main_w_arg);
GtkWidget *filter_te;
Initial revision svn path=/trunk/; revision=2
1998-09-16 02:39:15 +00:00
The text entry box that a filter construction dialog manipulates is 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-02-23 05:54:27 +00:00
filter_te = gtk_object_get_data(GTK_OBJECT(main_w),
E_FILT_FILTER_TE_KEY);
Add a dialog box for constructing expressions that test a field in the 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
2001-01-02 01:32:21 +00:00
dfilter_expr_dlg_new(filter_te);
Initial revision svn path=/trunk/; revision=2
1998-09-16 02:39:15 +00:00
}
Make the routines internal to the filter-editing dialog box static. 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
2000-02-12 06:46:54 +00:00
static void
From Joerg Mayer: use _U_ to flag unused arguments. svn path=/trunk/; revision=4878
2002-03-05 11:56:00 +00:00
filter_name_te_destroy_cb(GtkWidget *name_te, gpointer data _U_)
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
{
GtkWidget *main_w = gtk_widget_get_toplevel(name_te);
gtk_object_set_data(GTK_OBJECT(main_w), E_FILT_NAME_TE_KEY, NULL);
}
static void
From Joerg Mayer: use _U_ to flag unused arguments. svn path=/trunk/; revision=4878
2002-03-05 11:56:00 +00:00
filter_filter_te_destroy_cb(GtkWidget *filter_te, gpointer data _U_)
In the process of destroying a filter editing dialog box, we get a 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-21 01:45:07 +00:00
{
GtkWidget *main_w = gtk_widget_get_toplevel(filter_te);
gtk_object_set_data(GTK_OBJECT(main_w), E_FILT_FILTER_TE_KEY, NULL);
}