On Sam, 2017-07-29 at 11:35 -0600, jme...@anestheticaudio.com wrote: > Going through Alex's excellent documentation made me think about how > nearly every single new PD user I encounter struggles with OS > specific problems when it comes installing externals. As a teacher > who introduces a lot of new people to PD - I see this a LOT.
I hear you. > The standard place for putting externals on OSX (~/Library) is hidden > by default - and various versions of OSX require various ways of un- > hiding. Yeah. But why is unhiding necessary in the first place? From what I understand, Deken suggests the first writable search path it finds, so the user usually doesn't need to do anything at all but let Deken download the external to the right place. > Similarly the windows path is hard to find - and permissions and view > settings need to change to make that folder as well. Entering '%appdata%' into windows explorer is not _that_ difficult, but I agree with you anyway. I don't see why you need to change permissions or view settings. %appdata% directs you to the user-specific (thus user-writable) application data folder. > So even once the users understand they need to *make* a folder - > their OS stops them from making it in the right place. Yes, this is clearly user-unfriendly. It's a contradiction not to create the right directory and force it to be located in some hidden place. That's why I'm a proponent of automatic search path directory creation (at least the user-specific one). At least on Linux, we're already there: If Deken doesn't find a writable path, it suggests to create ~/.local/lib/pd/extra and - if confirmed - puts externals there. Your experiences might stem from Pd 0.47.1 where Deken did _not_ create any directory automatically. I think the best people can do now is to report specifically when Deken does not do something sensible per default. By 'sensible' I mean that the downloaded external is extracted to one of the search paths, so that it can be loaded with [declare -stdlib <external>] or [declare -stdpath <external>]. If Deken does always behave in a sensible way, then there isn't a strong necessity to have a more user-visible search path, or is there? Roman
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list