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
