[PD] Re: Mac OS X installer with library documentation
hans at eds.org
Tue Mar 29 22:55:55 CEST 2005
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
> 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
> 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.
> 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:
> Simon Wise
"Computer science is no more related to the computer than astronomy is
related to the telescope."
More information about the Pd-list