On Nov 27, 2013, at 14:12 , Graham Cox <graham....@bigpond.com> wrote:
> We’ve had rare cases in the past where a prefs file has caused an issue. > Obviously we did not anticipate it, otherwise it would have been discovered > in testing and fixed before it got out into the wild, but we know that > nobody’s perfect, and not every case can be tested for. Therefore we approach > things with the cautious knowledge that no matter how hard we try, there will > always be bugs. Since we’ve experienced bugs caused by prefs in the past, > it’s not impossible that there could be other bugs triggered by bad prefs in > the future. We need to have something up our sleeves if that occurs (like > having a fire department). Deleting the prefs file has been an acceptable > solution in the past because we know it’s super-rare that it’s needed. We > always follow up where we can and find out the real cause and fix it, so > these problems are virtually non-existent now, but we can’t be 100% certain. > > One of the things that our app allows is that the user can build vector > “styles” in pretty much any way that they can imagine. It means that there > are literally billions of combinations. Each tool in the app might be working > with any style at any time, and as a courtesy to the user we save the tool’s > style data in the prefs so they can pick up where they left off. When we’ve > had a problem with prefs, it’s usually turned out to be a user-built style > that contains crazy values. We’ve worked extremely hard to make sure “crazy” > values are impossible, but you can only make an app foolproof, not damn fool > proof, and occasionally something totally unanticipated slips through. These > days such occurrences are very rare, but as I say, we can’t guarantee there > is certainty, given the sheer number of combinations making it impossible to > test them exhaustively. > > But the other reason it’s nice to have a quick way to restore the original > defaults is in development and testing itself, so that a “clean install” can > be tested as well as an update where an existing set of prefs needs to be > considered. In this case the command line is fine, but clicking a button even > better. Even developers and testers like an easy life. You make reasonable points, but the fact that your explanation does a lot of tap dancing to get there might suggest an overreaction (in the need for a button, I mean, not in the explanation). And, a button is an awfully visible UI element for what should be so rare a problem. In these circumstances, I’d suggest you consider an “alternate” menu item, rather than a button. For example, an alternate to <your app> —> Preferences…, but with the Option key held down. That way, it’s hidden normally, but the reset procedure is easy to explain, even to damn fools. Plus, it’s really, really easy to set this up IB these days. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
