Are you sure it is better to store the extra externals, projects and abstractions in a user specific directory. Max/Msp for XP stores those in a common folder (I think c:\program files\common\max).
Tom
On Mar 30, 2005 1:11 PM, B. Bogart ben@ekran.org wrote:
Hey HC (again!)
Having system abstractions in one folder extra/ in the pd.app and the user-added abstractions in a separate place ~/Library/Pd/extra is a problem for pixelTANGO.
In pixelTANGO we have a folder of abstractions abstractions/
Inside this abstraction is an fx/ sub-folder that contains special purpose abstractions. These abstractions are just pixel effects and they all have a standard interface. These abstractions are dynamically read into PD and instanciated. (via dir2abstractionArray.pd) The PD patch needs to contain the path to these abstractions, just the search-path is not enough. Currently they are hard-coded in /Applications/PixelTANGO/abstractions/fx
This is the watched folder for new abstractions that user may (hopefully will) contribute. To search both the pd.app abstractions folder and the home directory in the patch would be pretty damn complex... (it is already complex!!)
I do really like the idea of being able to add custom externals in my home directory and replacing only the pd.app to only replace the standard objects. I don't know how to resolve this conflict.
B.
Hans-Christoph Steiner wrote:
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