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?

--------
Dan Wilcox
@danomatika
danomatika.com
robotcowboy.com

On Sep 28, 2015, at 4:00 AM, pd-dev-request@lists.iem.at wrote:

From: IOhannes m zmölnig <zmoelnig@iem.at>
Subject: Re: [PD-dev] loading classes: search by directory rather than extension
Date: September 27, 2015 at 2:27:06 PM MDT
To: pd-dev@lists.iem.at


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).

famdsr
IOhannes