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

On Sam, 2017-07-29 at 11:35 -0600, jmejia@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@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list