[PD] Re: Mac OS X installer with library documentation

[Hans-Christoph Steiner]

On Mar 27, 2005, at 12:01 AM, simon wise wrote:

>
> On 27 Mar 2005, at 8:28 AM, Hans-Christoph Steiner wrote:
>
>> The Pd .app and Win installer should be viewed as any other  
>> application: a set of code that users don't modify.  This is key to  
>> keeping it consistent across platforms and distributions.  User  
>> modifications should be kept elsewhere.  For example, in MacOS X, we  
>> could have standard folders like ~/Library/Pd/Externals and  
>> ~/Library/Pd/Help which are added to the path by default.    
>> Therefore, when upgrading, users won't have to redo all of their  
>> changes, they can just delete the Pd.app and put the new one in place  
>> and all of their customizations would remain in place.  This also  
>> means that extra, doc, etc. should remain enclosed inside of Pd.app.
>>
>
>
> ~/Library/Application Support/Pd  (or /Library/Application Support/Pd)  
> would be the usual OSX place to put directories intended to be used by  
> the user, many .apps use search paths like
>
>    ~/Library/Application Support/Pd/subfolder
>    /Library/Application Support/Pd/subfolder
>    $PATH_TO_APP/Contents/Resources/subfolder
>
> for every subfolder that should have both default/built-in parts and  
> custom user parts - that way it gives the possibility for a general  
> local set of defaults as well as individual user additions, and if  
> like me you have a couple of users set up (one with system and  
> application preferences for current live performance situations, the  
> other for the rest of the time so that I can switch back to my  
> performance settings very quickly and easily) then it is easy to set  
> up a particular set of extras and preferences to use in a show, while  
> still keeping a more general set.

I like the idea of keeping the subfolder names the same, but the  
"Application Support" gets really long.  And there are precedents for  
the ~/Library/Pd way, like ~/Library/Mail.

> The same could be done with the .plist - so that the $HOME one took  
> precedence, but the one inside Pd.app could easily be used to share a  
> version with certain externals and defaults already set. An extra item  
> in the .plist to make pd launch with only these defaults would make it  
> possible to have a specially set up .app for a particular patch - set  
> to open that patch on launching without worrying about other  
> preferences that may have been set for that user. I am using .command  
> files with the -open and other flags for this purpose, but it opens  
> with the Terminal window in front and the Wish interface.
>
> A structure like this would also make it easy to have different sets  
> of externals for different kinds of work by creating new users (maybe  
> one for Gem/video work and another for audio work) with their  
> associated preferences, external collections etc being quite distinct.

Various Pd-*.command files could easily swap in and out various  
~/Library/Preferences/org.puredata.*.plist files to start different  
configs.

>
> Finally it would be a nice touch for the installer to put symbolic  
> links to pd, pdsend, pdreceive etc from their old locations in  
> /usr/local so that they are in the right place for scripts which may  
> not know where to find Pd.app and and so they are in the terminal  
> search paths.

Yes it would be indeed.  I was planning a Pd-for-UNIX.pkg to do stuff  
like that, also including the headers.  Feel free to beat me to it.

.hc

> Maybe some useful models (gvim and gvim.app which work a bit  
> differently to Vim.app) could come from the OSX version of Vim see:  
> http://macvim.org/OSX/
>
>
> Simon Wise
>

________________________________________________________________________ 
____


"Computer science is no more related to the computer than astronomy is  
related to the telescope."
                                                      -Edsger Dykstra