Re: "First Run" installation of Application support stuff?
Re: "First Run" installation of Application support stuff?
- Subject: Re: "First Run" installation of Application support stuff?
- From: Mike Ferris <email@hidden>
- Date: Thu, 19 Dec 2002 12:53:44 -0800
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@hidden>
Date: Thu Dec 19, 2002 12:52:55 AM US/Pacific
To: Mike Ferris <email@hidden>
Cc: email@hidden, Steven Burr <email@hidden>
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@hidden>
Date: Sun Dec 15, 2002 1:27:37 PM US/Pacific
To: email@hidden
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@hidden>
Date: Sat Dec 14, 2002 9:16:21 PM US/Pacific
To: email@hidden
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@hidden
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@hidden
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@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.