Re: Strategy for naming support folder
Re: Strategy for naming support folder
- Subject: Re: Strategy for naming support folder
- From: j o a r <email@hidden>
- Date: Fri, 10 Oct 2008 00:27:54 -0700
On Oct 10, 2008, at 12:06 AM, Kyle Sluder wrote:
Preference files are opaque; the user's interaction with preference
files should be (ideally) through the app's UI or through the
`defaults` tool. There are legitimate use cases for accessing the
Application Support folder through the Finder, if the files therein
are meant to be treated as such (plugins come to mind). Ideally such
circumstances should be infrequent and well-defined; most interaction
with Application Support should probably be done with app-specific UI
instead.
Can you give a concrete example? I would argue that you're doing
something wrong if you ask your user to muck around in ~/Library.
There are better ways of solving the plugin problem - as demonstrated
by both System Preferences and Dashboard.
(As a side note, I'm not a fan of the naming scheme used for
preference files. The hierarchical naming scheme used for preference
files is merely conventional; they don't factor into the defaults
hierarchy at all. The system also provides no conveniences just
because there's a plist file whose name matches your app's bundle
identifier.)
I'm not sure that I get what you're saying here, but I think I have to
disagree: The functionality of NSUserDefaults is directly tied to your
bundle identifier.
The name is also not as stable as the bundle identifier. The name
of the app
could, for example, be localized in the Finder. The name of many
apps also
include a variable suffix, like a version number, " Lite", et.c.
So? There's no mandatory correlation between an app's name and where
it looks in Application Support. There's nothing preventing BBEdit
Lite.app, for example, to look in both ~/Library/Application
Support/BBEdit{, Lite}. Version numbers probably shouldn't be used in
the app's name anyway.
My comment was not on how the application itself would find it's
support folder. You suggested that using the name of the bundle would
make it easier for the user to find the support folder, and I argued
that this is not always the case - in particular for localized versions.
You're going to be hardcoding the name of the folder anyway, whether
that hardcoding happens to be in the form of a string in your source
code or the CFBundleIdentifier in your Info.plist. Why needlessly
inconvenience the user when you derive no benefit?
I don't agree. Using a predictable, rather than arbitrary, naming
scheme for auxiliary resources benefits everyone. I also get the added
benefit of having a unique name for my support folder, avoiding
potential collisions.
I don't think that we need to take this any further though. Let's just
agree to disagree.
j o a r
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden