Re: "First Run" installation of Application support stuff?

FROM : Mike Ferris
DATE : Thu Dec 19 21:53:44 2002

Bill Bumgarner actually let me in on this same piece of data.  Thanks.

I am not a perl jockey by any stretch of the imagination, so I probably
won't be fixing this one...  I had been thinking of making a couple
improvements to FinkCommander, though, when I get a chance...

Mike


Begin forwarded message:

> From: Ben Hines <<email_removed>>
> Date: Thu Dec 19, 2002  12:52:55 AM US/Pacific
> To: Mike Ferris <<email_removed>>
> Cc: <email_removed>, Steven Burr <<email_removed>>
> Subject: Re: "First Run" installation of Application support stuff?
>
>
> On Sunday, December 15, 2002, at 01:27  PM, Mike Ferris wrote:
>
>>    - A perl script for FinkCommander which presumably I would never
>> modify
>>
>
>
> That's there because your fink "prefix" path can be different for
> different users, so the app writes out the script with the path
> hardcoded if it changes. I believe that is the right place to put a
> script like that that gets modified.
>
> IMO the install prefix really should just be passed as an argument to
> the (static, in the bundle) script, though. If a perl geek wants to
> help us with this, send me your mods. :)
>
> -Ben
>
>
>> From: Mike Ferris <<email_removed>>
>> Date: Sun Dec 15, 2002  1:27:37  PM US/Pacific
>> To: <email_removed>
>> Subject: Re: "First Run" installation of Application support stuff?
>>
>> This is not directed at any specific person (although I could direct
>> it at a number of companies whose apps I have tried...)
>>
>> I would just like to make a plea for NOT putting stuff in
>> /Library/Application Support/Whatever without thinking really hard
>> about it...  For example, don't just copy a bunch of stuff in there
>> that could just as easily be in the app wrapper...  If you want to
>> support machine-wide optional stuff in that location, fine.  But
>> applications that simply copy a bunch of stuff there for no good
>> reason (you know who you are) are annoying.
>>
>> Same goes for ~/Library/Application Support/Whatever, but in this
>> case, copying or creating stuff there is more forgivable, if it is
>> something that makes sense.  But consider alternatives to this
>> location as well (such as using NSUserDefaults for preferences).  And
>> note that if the user will never change or add to the stuff you put
>> there (directly or indirectly), why are you putting it there?  Keep
>> unchanging stuff in your app wrapper where it won't clutter up my
>> home directory or system install locations.
>>
>> In my ~/Library/Application Support folder I have the following kinds
>> of stuff that seem OK
>>
>>    - Preference-type info that is too large to be in NSUserDefaults
>> (like PB workspace templates, LaunchBar configuration data, etc...)
>>    - High score lists for games (although arguably this could be in
>> NSUserDefaults)
>>    - License info (again, arguably could be in NSUserDefaults)
>>    - AddressBook data (although I would rather recent Apple apps
>> allowed multiple "documents")
>>    - Omniweb bookmarks, cookies, etc...
>>    - Terminal startup file which I created
>>    - Watson plugins (that were downloaded and installed separate
>> from Watson itself)
>>
>> And I have the following stuff which seems like it should not be there
>>
>>    - A perl script for FinkCommander which presumably I would never
>> modify
>>    - Lots of preference data that should clearly be in NSUserDefaults
>>
>> Mike Ferris
>>
>>
>> Begin forwarded message:
>>
>>> From: Dave Yost <<email_removed>>
>>> Date: Sat Dec 14, 2002  9:16:21 PM US/Pacific
>>> To: <email_removed>
>>> Subject: Re: "First Run" installation of Application support stuff?
>>>
>>> At 9:09 AM -0500 2002-12-09, Jeff Disher wrote:
>>>> I wasn't referring to finding the folder.  I was referring to
>>>> actually working with its contents.  That is, checking that a
>>>> folder exists for your app (probably using the bundle identifiers
>>>> like preferences do), providing facilities for a generic storage
>>>> dictionary like the preferences, and the ability to get a path to
>>>> your application's folder in Application Support for storing things
>>>> that you need to write directly (if you are just copying a file,
>>>> for example).  It could also handle the sort of synchronization
>>>> that Dave was referring to in his original post.
>>>>
>>>> This isn't supposed be to be anything ground-breaking, just a small
>>>> object to make some of these tedious checks and serialization calls
>>>> a bit more convenient.
>>>
>>> Actually I should have mentioned the issue of getting user
>>> authentication for writing into /Library.  Is there ready-to-go Java
>>> code to wrap around stuff requiring administrator authentication? 
>>> That should be part of the library.
>>>
>>> Dave
>>> _______________________________________________
>>> cocoa-dev mailing list | <email_removed>
>>> Help/Unsubscribe/Archives:
>>> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
>>> Do not post admin requests to the list. They will be ignored.
>> _______________________________________________
>> cocoa-dev mailing list | <email_removed>
>> Help/Unsubscribe/Archives:
>> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
>> Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | <email_removed>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.