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

[B. Bogart]

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
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20050330/99fba4f5/attachment.pgp>