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

[Hans-Christoph Steiner]

That's a good point which I forgot.  My main point is that we should  
try to set things up so that the Pd.app never needs to be modified, so  
that upgrades are just a matter of deleting one Pd.app and swapping in  
the new one.  (This applies to all platforms, of course, just not the  
.app part;).

In the MacOS X way, there are two mirrored locations for such  
application extensions: system (/Library/Pd) and user (~/Library/Pd).   
So on Windows we could have "C:\Program Files\Common\Pd" and  
"C:\Documents and Settings\username\...blah blah...\Pd".  On UNIX, the  
same idea "/usr/local/lib/pd" and "~/lib/pd", or something like that.

.hc

On Mar 31, 2005, at 11:20 PM, Thomas Ouellet Fredericks wrote:

> 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 at 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
>>>
>>>
>>
>>
>>
>>

________________________________________________________________________ 
____

                                     http://at.or.at/hans/