[PD] New deken feature, create system user folder (was how-do-i-install-externals-and-help-files page (was Re: Linux Global folder for externals)

Alexandre Torres Porres porres at gmail.com
Sat Mar 4 17:32:55 CET 2017

Oh, please allow to reason that even if the new deken feature, as it'll
also remember the last choice and keeps it, it won't ever propose/create
that user folder again.

That's actually an issue even if it proposes to download to the user
folder, no matter what, at first, because if you do not choose it the first
time, it'll never propose it again.

if we're gonna stick to the idea of no making pd create the folders, but
deken, I think it'd be nice if there was a menu of regular folder paths it
can install to, and then query the user to create the folder if it doesn't
exist. Such folders would be the application, user and global, for each
system, of course. If you wanna download somewhere else, a 4th option could
be "other", which opens the savemenu dialog.


2017-03-04 13:09 GMT-03:00 Alexandre Torres Porres <porres at gmail.com>:

> 2017-03-04 13:00 GMT-03:00 Alexandre Torres Porres <porres at gmail.com>:
>> the whole discussion here seemed to be the need to create that folder
>> automatically, to make things easier for the user.
> I dont know if it's clear what a complex user experience it is to manage
> externals in Pd right now. Seems that the whole idea with deken and all was
> to make it painless, but we're not there yet.
> Why creating such folders (like the user folder) would be better for the
> user? Cause now it's just hard because you need to create the folder
> yourself, and that requires, first of all, prior knowledge on how pd works
> internally, which might be fine for developers, but not to users... second,
> the ~/Library isn't  normally viewable in the finder on a Mac, so you also
> gotta have knowledge that it this folder is hidden, where it is hidden, and
> how to hack the system so you can see it...
> Yes, this is for the Mac, but other systems have other peculiarities,
> which just unfolds and adds complexity. But they do have a similar
> logic/idea, that the user doesn't or shouldn't have to touch some folders,
> since they can be dummies who may screw up and compromise the system.
> Therefore, is it the *Software* that creates folders in such a place...
> but not Pd... and the decision to not do it was consciously made, but I
> still don't know why.
> I have asked a few times now, I still have no answer to why there's a good
> reasoning not to do it when Pd is installed on your machine... I looked for
> previous discussion in the list, I couldn't find, any possibility anybody
> would join in and answer me please?
> Anyway, since Pd does not create it, for some reason, we're down to giving
> that task to the deken plugin, but it's not quite there yet. Nonetheless, I
> still think the best solution is that Pd installs the system folders
> automatically when it is installed (not only the user-specific in
> *~/Library*, but also the global in */Library*).
> Other features that would make things easier for the user is that if both
> deken and the "Preferences => Path" tab had easy access to the folders Pd
> automatically searches for externals (global, user and application). As it
> is, it's simply impossible to navigate to the user-specific folder and also
> to the application folder. On the other hand, I can actually navigate to
> the system folder (/Library) just fine in Mac Os.
> So, as it is, the most convenient place for mac users to install externals
> is the global folder, so they can easily navigate there in the Path... or
> in the Finder to manually drop or delete folders. That is, if only it had
> been created there...
> I hope I have made it clear how complicated and still somewhat painful
> managing externals in Pd still is, and how there's much room por
> improvement! It was only when I sat down and wrote a 13 page tutorial on
> how to manage externals that I realized how hard it is, cause I didn't even
> addressed all of these issues.
> cheers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20170304/6280d704/attachment-0001.html>

More information about the Pd-list mailing list