<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 10pt; font-family: "Courier New",Courier,monospace'>
<p> </p>
<div> </div>
<p> </p>
<p>On 2017-07-29 15:42, Roman Haefeli wrote:</p>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">
<div class="pre" style="margin: 0; padding: 0; font-family: monospace">On Sam, 2017-07-29 at 11:35 -0600, <a href="mailto:jmejia@anestheticaudio.com">jmejia@anestheticaudio.com</a> wrote:
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">Going through Alex's excellent documentation made me think about how<br /> nearly every single new PD user I encounter struggles with OS<br /> specific problems when it comes installing externals. As a teacher<br /> who introduces a lot of new people to PD - I see this a LOT.</blockquote>
<br /> I hear you.<br /><br />
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">The standard place for putting externals on OSX (~/Library) is hidden<br /> by default - and various versions of OSX require various ways of un-<br /> hiding.</blockquote>
<br /> Yeah. But why is unhiding necessary in the first place? From what I<br /> understand, Deken suggests the first writable search path it finds, so<br /> the user usually doesn't need to do anything at all but let Deken<br /> download the external to the right place.</div>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>
</blockquote>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace">Unhiding is necessary in order to make the required ~/Library/Pd. It has no writeable path on a default OSX install.</div>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace">The problem here is simply that there needs to be a standard path that Pd searches for that is also considered userspace by OSX. </div>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">
<div class="pre" style="margin: 0; padding: 0; font-family: monospace"><br />
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">Similarly the windows path is hard to find - and permissions and view<br /> settings need to change to make that folder as well.</blockquote>
<br /> Entering '%appdata%' into windows explorer is not _that_ difficult, but<br /> I agree with you anyway. I don't see why you need to change permissions<br /> or view settings. %appdata% directs you to the user-specific (thus<br /> user-writable) application data folder.<br />
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">So even once the users understand they need to *make* a folder -<br /> their OS stops them from making it in the right place.</blockquote>
<br /> Yes, this is clearly user-unfriendly. It's a contradiction not to<br /> create the right directory and force it to be located in some hidden<br /> place. That's why I'm a proponent of automatic search path directory<br /> creation (at least the user-specific one). At least on Linux, we're<br /> already there: If Deken doesn't find a writable path, it suggests to<br /> create ~/.local/lib/pd/extra and - if confirmed - puts externals<br /> there. </div>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>
</blockquote>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace">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.</div>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace">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!</div>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">
<div class="pre" style="margin: 0; padding: 0; font-family: monospace"><br /> Your experiences might stem from Pd 0.47.1 where Deken did _not_ create<br /> any directory automatically. I think the best people can do now is to<br /> report specifically when Deken does not do something sensible per<br /> default. By 'sensible' I mean that the downloaded external is extracted<br /> to one of the search paths, so that it can be loaded with [declare<br /> -stdlib <external>] or [declare -stdpath <external>]. </div>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>
</blockquote>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace">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.</div>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">
<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace"><br /><br /> If Deken does always behave in a sensible way, then there isn't a<br /> strong necessity to have a more user-visible search path, or is there?<br /><br /> Roman</div>
<br />
<div class="pre" style="margin: 0; padding: 0; font-family: monospace">_______________________________________________<br /><a href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br /> UNSUBSCRIBE and account-management -> <a href="https://lists.puredata.info/listinfo/pd-list">https://lists.puredata.info/listinfo/pd-list</a></div>
</blockquote>
</body></html>