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
On 09/28/2015 06:50 PM, Dan Wilcox wrote:
Currently, GEM requires it’s dynamic libs to live in the “lib” folder in the main app bundle Contents.
no, i'm pretty sure it does not. it's only Pd-extended that set the search paths in the Gem binaries to look for auxiliary libraries in that "lib" folder.
it's easy enough to make the search paths local to the `Gem.pd_darwin` (or rather: the various `gem_plugin*.so` files), so that they are looked for in .../Gem (or .../Gem/libs/, which is what i prefer)
fmdsr IOhannes
Ah ok. Honestly I haven’t built/installed GEM from scratch on OSX, beyond looking into the AVFoundation stuff*. I mainly just copy the pd-extended GEM into sucessive versions of Pd Vanilla and was thinking it would be really nice to be able to install it on OSX with deken instead.
* I finished my MFA and recently started a 1 year visiting teach position in Denver, so I’ll be finally be able to dedicate some (paid!) time to getting the GEM OSX updates working. It’s on my list after redoing my websites & finalizing PdParty. :D
-------- Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Sep 28, 2015, at 11:34 AM, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 09/28/2015 06:50 PM, Dan Wilcox wrote:
Currently, GEM requires it’s dynamic libs to live in the “lib” folder in the main app bundle Contents.
no, i'm pretty sure it does not. it's only Pd-extended that set the search paths in the Gem binaries to look for auxiliary libraries in that "lib" folder.
it's easy enough to make the search paths local to the `Gem.pd_darwin` (or rather: the various `gem_plugin*.so` files), so that they are looked for in .../Gem (or .../Gem/libs/, which is what i prefer)
fmdsr IOhannes
-
Dan Wilcox -
IOhannes m zmölnig