[PD] New users and external path struggles

[Roman Haefeli]

On Sam, 2017-07-29 at 11:35 -0600, jmejia at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20170729/637b2dc2/attachment-0001.sig>