[PD] New users and external path struggles

[jmejia at anestheticaudio.com]

On 2017-07-29 15:42, Roman Haefeli wrote:

> 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.

Unhiding is necessary in order to make the required ~/Library/Pd. It has
no writeable path on a default OSX install. 

The problem here is simply that there needs to be a standard path that
Pd searches for that is also considered userspace by OSX.  

>> 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.

You may be right about windows - I have less experience with that...
maybe it was just user struggles with figuring out what %appdata% even
means. 

Auto creation of a folder would be fine with me - but I've seen a lot of
resistance to that idea. I think simply having ~/Documents/Pd in the
list of standard path's would solve this problem in a big way! 

> 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>].

I'm definitely talking about a current situation. On a default
installation of OSX, deken has no useable place to install - and you can
not install externals. My process, and the process I have taught others
is to google for the paths.. and then google for your OS specific ways
to un-hide ~/Library - the directory you need to see in order to create
the Pd folder. 

> 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 
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20170730/752eb2af/attachment.html>