Re: FSCopyObjectAsync: useless and crippled
Re: FSCopyObjectAsync: useless and crippled
- Subject: Re: FSCopyObjectAsync: useless and crippled
- From: "Mark Munz (DevList)" <email@hidden>
- Date: Mon, 16 May 2005 15:02:05 -0500
On May 16, 2005, at 11:34 AM, Ondra Cada wrote:
BOA = Background Only Application, daemon if you like (although
it's more a UIElement Cocoa app than a true Unix daemon).
Such a thing does not belong to /Library nor ~/Library, but into
the application package Resources subfolder.
Oh, I'm happy to run it out of the Application package, except that
when you do that, the Finder will no longer let you replace the file,
since it's in use. I don't know, maybe there is some trick that I am
not aware of to allow my helper app to shutdown if the Finder wants
to replace it.
So now it seems -- even if I don't copy a file to the /Library
folder, I'm still forced to either:
1. Require the user to manually move the original file to the trash
before copying, since they will get an error if the Finder tries to
replace the file.
2. Use an installer that quits the BOA and installs the app.
From a user's stand point, drag-n-drop installation is much
friendlier than forcing the use of an Installer.
Quite the contrary, at least from *this* user's standpoint :)
You seem to advocate Installers for all software (since even copying
to /Applications would require admin rights), but I don't think
that's indicative of most real users out there.
Apple certainly recognizes that point and at least all the talks I've
been too regarding UI (and I've been to several now), they seem to
push towards Drag-n-Drop installers (or First Run Fix) unless an
installer is really necessary, like an kext or LOTS of files that
needs to go in /Library or some such.
I'd be tickled pink if I could run my helper app from its location in
the package and still be able to replace the file. Since I can't do
that, I copy the file into ~/Library where I can replace it with a
new one the first time the new version is run.
Mark Munz
_______________________________________________
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