Re: Installing to /Users/<username>/...
Re: Installing to /Users/<username>/...
- Subject: Re: Installing to /Users/<username>/...
- From: Karl Kuehn <email@hidden>
- Date: Sun, 31 Oct 2010 11:11:16 -0700
On Oct 31, 2010, at 9:08 AM, eveningnick eveningnick wrote:
> The problem with my app is that it needs to install some other files, except that plist. Installer, besides creating .plist, copies some "template" documents to the user folder (more specifically, to /Users/<username>/Library/Application Support/MyAppName/...) and provides uninstaller as well (an Applescript bundle).
None of this changes where your application should be stored:
- If you have user-specific application support files, then those should be copied into place when the user either first launches or, better yet, first needs those files. This should never be a part of the installer, since there could be multiple users on the system, some of whom have yet to be created. As an example think about a school computer lab where hundreds of people may log in with their own home directory on any one of hundreds of computers. If your program can work elegantly in that situation then you probably have done things the right way.
- My second point here is that you should at least re-think the idea of template documents. Is this something that the majority of your users are actually going to customize? Could you just keep using the template documents onboard your app (in Contents/Resources), and then offer a button to copy this out for only the users that need them?
Again the example to think about is the school lab, and here the poster child for doing it wrong is MS Office. In order to launch MS Word the Office Setup Assistant needs to create the user database, a 20-30 MiB file. The fast majority of this file is to support Outlook/Entourage, and the only thing that Excel and Word use from it are a few personal details. So for labs that don't use Outlook/Exchange they are still creating 20-30 MiB files per user and storing them on a server. Do you really need to follow this example? Or could you better use individual preferences to override the settings you want to offer?
- So if you have managed to drop the weight of all of the stuff that you were going to copy into place, then you have probably eliminated the need for any sort of uninstaller, also dropping that need (and the need to put a folder into */Applications). So now you are back to an app that is naturally drag-and-drop.
My general feeling is that unless you are installing something like a kext, or components that are shared by multiple, separately downloaded, applications, needing an installer is real evidence of need to re-think how the application works.
> I want to create installer, because the presence of an installer is a sign for a user that application "does something more that just runs when the bundle is double clicked". And if i provide only an application bundle, the user will feel tempted to just move it to trash when he doesn't need my application.
You are making the mistake that people will remember how things installed, and make this differentiation that you find. In my experience neither is the case.
> This plist file, that is supposed to launch my app everytime the system starts, will cause problems (because, user had qlreqdy moved bundle to trash, Launchd can't find app's executable - it'll pop up that annoying message every 10 seconds). These template documents, that i install to /Users/<Username>/Library/Application Support/MyAppName... will take some of the disc space like a garbage that otherwise would have been cleaned by uninstaller, etc
I don't know what your app actually does, but why are you using Launchd to do this? And why do you need the app crash protection turned on? For GUI apps (and I presume that is the case here) a launch item is a better solution, and provides something that the user can turn on and off themselves. Plus it only will annoy them once on login if things are broken.
And if you absolutely need to use a LaunchAgent setup to do this, you can create ~/Library/LaunchAgents and put your files in there. It will only apply to that single user, and all the files can be properly non-admin modifiable.
And beyond what I wrote above about the template files... are your files really that big that leaving behind some per-user customization is going to be anything other than a rounding error when we are looking at the disk? If so, then I think you have to re-think things (ala the MS Office example from above).
> I just want to make it obvious and intuitive for a user, that he should uninstall the app the same way he installed it - using an installer or uninstaller.
>
> That's why i need an Installer (just like Microsoft Office does). I am aware of that it is not recommended to install a decent application in any other way than copying a bundle.
I think you are making two mistakes here: 1) holding out MS Office as an example of something that does it right (they have come a long way, but are still working at it). 2) I think you have missed that (at least before Office 11) you can drag-and-drop MS Office, and it will then take care of user setup when first run (doing more than it should...).
> I am considering also a possibility to install all the files not to user home directory, but to /Library/Application Support/MyApp... and /Library/Launch Agents/MyApp/... , but: my application needs to manage that plist file (it should be possible for it to create that file, modify it or delete it). Unfortunately, the system doesn't let me to do that - an application doesn't have enough of privileges. Maybe if i solved this problem, i wouldnt have needed that $user variable from a script. Although i have no idea how to modify a file in /Library/LaunchAgents/... from an "ordinary user" application.
> Can it be done somehow?
Can it be done? Yes. But I think I have made my case that it should not be done.
--
Karl Kuehn
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Installer-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden