[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: defaults randomly being overwritten?

From: Tim Harrison
Subject: Re: defaults randomly being overwritten?
Date: Sat, 20 Jul 2002 10:20:44 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529

Jeff Teunissen wrote:

Well, it will always have the ability. The problem is that it's happening
without an explicit action asking for it. :)

It would only always have the ability if the application were able to effectively say "remove everything in the defaults directory", as opposed to "modify the defaults file for my application".

That said, separate files make it more difficult for bad things to happen.
Separate files also make it more difficult for good things to happen
correctly. The question is, is the benefit greater than the danger?

Yes.  Randomly wiping out people's configurations is a Bad Thing[tm].

From a primarily non-coder point of view, I can't see how having separate files for individual application defaults is all that difficult. Aside from having to code for that situation, the benefit of not allowing one application to destroy all defaults (which is a royal pain in the gluteus) is a significant one.

As a user, if you configured your system to do [A], and, seemingly at random, your system decided to clear that information, and do [B], you'd be furious. I certainly would be. Make all obligatory comments about Windows here. ;)

Once again, I don't know if this is a GNUstep bug, or an application bug, or both. I just think there could be better protection for user defaults, which would not cause more problems than it would solve.

No, it wouldn't be beneficial if NSGlobalDomain were read-only -- how
would one change it without manual editing?

Preferences modules, for example, need to edit the global domain.

You will note that I didn't say "make NSGlobalDomain read-only", but I understand what you mean. Point taken.


Tim Harrison

reply via email to

[Prev in Thread] Current Thread [Next in Thread]