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

[B. Bogart]

PWD works fine, BUT since the folder is watched by an abstraction, not
by the parent PWD only returns the parent value. According to Miller
there is no way to get the path an abstraction was loaded from. So the
path has to be in a standard place. in TOT I think this had to be
absolute due to ~ replacement, but I see in python we can do ~
replacement so I should be able to get the home directory path.

What I'm worried about is reading abstractions from two different places
into one array... at the moment I'm just thinking of concatenating the
two lists (with absolute paths) and just ignoring the fact they come
from different places.

I don't know how the ; pd-abstraction.pd stuff will work with possible
duplicate names... Also its harder (impossible) to open pixelTANGO
abstractions as a basis of new user contributions (since they would be
burried down in the .app.)

*sigh*

B.

Hans-Christoph Steiner wrote:
>
> Ah, Ok, I finally understand why you need this setup for pixelTANGO.
> You are banging against the current limitations of abstractions as
> objects: the path issues.  It seems that the [pwd] object that Frank
> proposed would help out here, but I don't know the status of it.
>
> .hc
>
> On Mar 30, 2005, at 1:11 PM, B. Bogart 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
>>>
>>>
>>>
>
> ________________________________________________________________________
> ____
>
>                   ¡El pueblo unido jamás será vencido!
>
>
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://iem.at/cgi-bin/mailman/listinfo/pd-list
>
-------------- 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/20050403/afb18517/attachment.pgp>