I’d also add a button to open the user’s externals directory. Beginners would start there and then quickly learn it’s location.
I also agree that the per-app hidden directory approach of Unix/Linux apps is pretty well understood. The comparison with Python, Ruby, etc make sense here as a user folder allows the user to modify/override the system without mucking with the main pd/extra. Again, this is particularly helpful on OSX due the app bundling. Only catch so far on OSX is adding a library search path so we could install externals that have library dependencies to a user folder. Currently, GEM requires it’s dynamic libs to live in the “lib” folder in the main app bundle Contents.
In that case, something like the following comes to mind:
~/.pd
~/.pd/externals
~/.pd/libs
Of course, the libs folder would really only make sense on Windows & OSX since Linux would just install the dependencies to /usr/lib or /usr/local/lib. I wonder how Python, Ruby, et al. deal with library dependencies? I suppose they statically link?
Subject: Re: [PD-dev] loading classes: search by directory rather than extension
Date: September 27, 2015 at 2:27:06 PM MDT
On 09/27/2015 10:18 PM, Martin Peach wrote:It would also be a good idea if the non-power user could see, from within
Pd, a list of all the directories Pd will scan for externals and
abstractions.
good idea (and so simple).famdsrIOhannes