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