Ethereal-dev: Re: [Ethereal-dev] Global Color Filters - Request for Comments
Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.
From: Richard Urwin <richard@xxxxxxxxxxxxxxx>
Date: Wed, 12 Mar 2003 09:05:22 +0000
On Wednesday 12 Mar 2003 5:45 am, Martin Regner wrote: > Guy Harris wrote: > >"get_datafile_path()" doesn't need a "for_writing" argument; the only > >reason "get_persconffile_path()" has one is to allow a > >backwards-compatibility hack to read configuration files from the days > >when, on Windows, configuration files were stored in a ".ethereal" > >subdirectory of the user's "home directory" (which isn't really the same > >thing on Windows as on UNIX). OK > >> The global colorfilters file resides in the "data directory"; > >> /usr/local/etc on my machine. This needs superuser permission to create, > >> but that is probably as required. Is this the correct place? Maybe we > >> need to create an Ethereal subdirectory? > > > >A subdirectory of the data directory might be a good idea, just to keep > >Ethereal's files separate from other files. (Actually, that > >subdirectory would *become* the data directory.) This would be a change for all Ethereal's data files. So the obvious solution would be for a create_data_dir() to create the directory if it doesn't exist, as the create_persconffile_dir() does at present. No problem, but a bit less localised than the current situation (6 files would need to be changed to suit the new API.) An alternate solution would be to create the directory in get_data_dir(), which would keep the API the same as it is, but may result in an empty directory. I think this would be my choice. (I said:) > >> The next time > >> Ethereal is started the global filters will again operate, giving the > >> possibility of a difference in behavior that the user is not expecting. > >> Is this a problem? > > > >I think it'd be a bit surprising if the user were to change filters, > >save them, and have a new session behave differently from the session in > >which they changed and saved the filters. > > > >It *would* be useful to let users remove the global filters permanently, > >if they didn't want them. If you save all filters to the local file, > >it'd probably be sufficient to read the local filter file if there is > >one and the global filter file if there isn't one, and perhaps have a > >"revert to factory settings" option to discard the local filter file. This sounds good. Howabout: The file dialog has a button to select the global file. The load button on the color dialog has options to prefix the loaded filters to the existing set, suffix them, or replace them. If the global filters are loaded and replace the current set, and are then saved with no further changes, then the local file is deleted. (Martin Regner wrote:) > I haven't thought so much about it yet and haven't read so much about the > previous discussions. But maybe it would be good to have a checkbox (or > similar) telling if a specific filter is active or not instead of having to > remove the entries you don't want to have active. The indication whether > the filter is active or not should be stored in the file so that the status > doesn't changed next time Ethereal is used. Maybe you want to have some > filters specified that you don't want to have active all the time. > > When you start Ethereal it should read the local filter file if there is > one and use the active ones in that file. If there is no local file it > should read the global filter file and use the filters in that one. If you > enter the color filter dialog you should maybe see both the entries from > the global file and the local file (both active and not active - together > with an indication whether they are active/not active and maybe also > whether the filter is global/local). > If you activate one of the global filters it should be stored in the local > filter file as active. The problem I see with this is that filters are often grouped, so to enable a given filter scheme you might have to enable several individual filters. It would be confusing to have multiple ways to achieve the same ends, so these checkboxes replace the saving to multiple filter files method. Multiple files are easier to maintain than a huge list of filters; if I have used a set of filters to diagnose problem X than I can leave the file around for the next time next year, if I was using checkboxes I would have those filters cluttering up the list and in all likelyhood would delete them and have to recreate them next year. -- Richard Urwin
- Follow-Ups:
- Re: [Ethereal-dev] Global Color Filters - Request for Comments
- From: Richard Urwin
- Re: [Ethereal-dev] Global Color Filters - Request for Comments
- References:
- Re: [Ethereal-dev] Global Color Filters - Request for Comments
- From: Martin Regner
- Re: [Ethereal-dev] Global Color Filters - Request for Comments
- Prev by Date: Re: [Ethereal-dev] RTP analysis. Same SSRC for several streams causes problems
- Next by Date: Re: [Ethereal-dev] Global Color Filters - Request for Comments
- Previous by thread: Re: [Ethereal-dev] Global Color Filters - Request for Comments
- Next by thread: Re: [Ethereal-dev] Global Color Filters - Request for Comments
- Index(es):
- Get Wireshark
- Download
- Code of Conduct