Personally I think we may be jumping the gun on assuming Apple's intentions based on enhanced security on the /Library/Application Support folder. Yes, I got burned as well, but I *still* plan on writing "all users" support files in the /Library/Application Support folder, even if I have to go the extra mile to make it happen.
Ken Ray Sons of Thunder Software, Inc. Email: k...@sonsothunder.com Web Site: http://www.sonsothunder.com/ On Jul 21, 2011, at 10:28 PM, Scott Morrow wrote: > To provide writable "application" files, one method I have used is to copy > these writable files (from the executable) into the user's > ~/Library/Application Support/ folder and then makes a note of this in the > /Users/Shared folder so that an admin account doing an uninstall can look one > place to see all the different user's Application Support folder(s) that have > files needing deletion. Having the application do this saves the installer > from needing to know about multiple accounts. And if more accounts are added > that need to use the application the executable just creates a new set of > files. > > Scott Morrow > > On Jul 21, 2011, at 6:40 PM, Josh Mellicker wrote: > >> >> On Jul 21, 2011, at 5:50 PM, Shao Sean wrote: >> >>>> On the topic of "where do we put stuff (needed support files) in OS X", I >>>> remember Ken Ray had a great article on this… we decided on >>>> /Library/Application Support/, it has been working great until yesterday >>>> :-) >>> >>> Best to just use the user's application support folder.. If I remember >>> correctly, Apple will deny your Mac App from the store if you try to write >>> to the system application support folder.. >>> >>>> We are now changing on OS X so that support files will be downloaded and >>>> housed inside the Mac application package in the Applications directory.) >>> >>> Always a bad idea, and this will cause your app to get denied from the app >>> store for sure.. >>> >>> While it is true that the majority of users are running as an admin account >>> on their own single-user machine and you can get around the limitations >>> imposed by Apple by running sudo commands, think about a >>> corporate/educational/shared environment where your attempt to run sudo >>> will fail, the elevated privs through AppleScript will fail (and even Rev's >>> new elevated privs feature will fail).. By coding according to the rules >>> laid out you can save yourself headaches in the future.. >> >> >> Hmmm…. I stand corrected. Now, we are getting an error message when trying >> to execute the sudo command. >> >> "sudo: no tty present and no askpass program specified" >> >> So, we are going to take Shao's sagely advice and try ~/Library/Application >> support. >> >> >> _______________________________________________ >> use-livecode mailing list >> use-livecode@lists.runrev.com >> Please visit this url to subscribe, unsubscribe and manage your subscription >> preferences: >> http://lists.runrev.com/mailman/listinfo/use-livecode > > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
