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 https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://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 mailto: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 mailto: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