On Sat, Mar 08, 2003 at 02:16:40PM +0000, Richard Urwin wrote:
> I have the first part of this as a first cut, and I would like any comments
> that people have.
"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).
> 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.)
> When the color filters dialog is invoked, all of the filters, global and local
> are displayed. When these filters are saved they are all saved to the local
> file, and the global file is not reread. So, on the current session, the user
> can remove the global filters if they wish. This (emergent) behavior seems to
> work well. What do you think? 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.
