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, [email protected] wrote: > > From: IOhannes m zmölnig <[email protected] <mailto:[email protected]>> > Subject: Re: [PD-dev] loading classes: search by directory rather than > extension > Date: September 27, 2015 at 2:27:06 PM MDT > To: [email protected] <mailto:[email protected]> > > > 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
_______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
