Re: [OT] Software Delivery (was Re: Why do "loose" nibs take precedence over nibs in .lproj?)
Re: [OT] Software Delivery (was Re: Why do "loose" nibs take precedence over nibs in .lproj?)
- Subject: Re: [OT] Software Delivery (was Re: Why do "loose" nibs take precedence over nibs in .lproj?)
- From: Charlton Wilbur <email@hidden>
- Date: Sat, 22 Jan 2005 07:00:03 -0500
On Jan 22, 2005, at 6:16 AM, Jeremy Dronfield wrote:
Also, I never install anything that comes with an installer, unless it
comes from Apple or some other supplier I know and trust.
This is something I'm thinking about right now. My current project is
likely to have *lots* of user-created files and plugins, by design.
The application is likely to ship with at least three plugins when it's
released, with a half-dozen more becoming available for registered
software. Installing files in different locations is exactly what an
installer is designed for, but it causes justifiable concern. Is it
reasonable to expect a novice user to be able to create a folder in a
specified place (in this case, either /Library/Application Support/App
Name or ~/Library/Application Support/App Name)? How savvy is the
average Mac user (or at least the average Mac user who's downloading
shareware) about this sort of thing?
Also, there will be a central repository of plugins, both official and
user-created. (Part of the incentive to allow the computer to phone
home and verify its registration is that the user will be notified of
new plugins for download.) Is it reasonable (with the user's explicit
permission, of course) to download these to the desktop and allow the
user to deposit them wherever he or she wishes? Or is it preferable to
download them directly to where they belong, perhaps by using user
defaults? In particular, I'd like to leave it up to the user whether
to use the system-wide Library or the user-specific Library.
Charlton
--
Charlton Wilbur
email@hidden
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden