Perfect timing! I was just reading up on NSUserDefaults, and remembered, "Didn't they say something about a command line defaults domain?" Sure enough.
So this sounds like a small utility project, which, given an application, uses the command line or standard Cocoa calls to retrieve user settings, possibly present the check-boxed list of which ones to make portable, and to generate a command line tool that calls the binary with the appropriate arguments.
The 'portablized' application itself is untouched, as the file is external text. No funky new inconsistencies on where to store the data, and if it is trashed, there is no loss. It's likely that the settings will even be portable between different versions of the app, if they maintain the same UserDefaults tags. All cocoa apps would support it out of the box, since this is an OS-level thing. And from the looks of things, the temporary changes will not affect actual user settings. Best yet, no .plist transport/library surgery required!
All that remains is to see if it would work the same on carbon apps.
by Blain — Oct 14
So this sounds like a small utility project, which, given an application, uses the command line or standard Cocoa calls to retrieve user settings, possibly present the check-boxed list of which ones to make portable, and to generate a command line tool that calls the binary with the appropriate arguments.
The 'portablized' application itself is untouched, as the file is external text. No funky new inconsistencies on where to store the data, and if it is trashed, there is no loss. It's likely that the settings will even be portable between different versions of the app, if they maintain the same UserDefaults tags. All cocoa apps would support it out of the box, since this is an OS-level thing. And from the looks of things, the temporary changes will not affect actual user settings. Best yet, no .plist transport/library surgery required!
All that remains is to see if it would work the same on carbon apps.