2018-03-08 17:44 GMT-03:00 Roman Haefeli <reduzent@gmail.com>:

At the risk of not being helpful to the issue by adding another
opinion, I disagree. Or rather: I do not really follow you.

That's quite possible, when it comes to me :/

I don't see any problem with deken installing into a hidden folder. It's a pretty
common thing on all OSs. Just a have a look at the contents of
~/Library, %AppData%\, ~/.local/ .

Yeah, that's not really the point. Perhaps this needs yet more contextualization. The idea that deken should create non existing (but needed/relevant) folders is old. It comes from a resistance that Pd should create such folders automatically, so, as a solution, you could do that inside Deken, and Pd wouldn't impose the creation of such folders.

A further aggravating factor is that one of such supposedly needed/relevant folders, in macOS, became hidden since 10.6, and this would be "~/Library/Pd". So it became quite inconvenient and counterproductive, so we needed a better default place to keep externals.

Now, well, does Pd have files somewhere inside ~/Library? Yeah, but where? In ~/Library/Preferences. Does Pd need a "Pd" folder inside ~/Library for its documents? No, to the extent that Pd doesn't even create a folder there on its own there...

And do we need Pd documents and externals in hidden places? Does it have any advantage? No, it doesn't. And in fact, such folder wasn't chosen because it was hidden. It became hidden and inconvenient. It's not that having a hidden folder for externals in macOS was intended by design and principle in the first place.

You say: "Newbies have troubles finding the folder"

I say: "Newbies shouldn't have to know about it all"

What is the advantage of keeping externals in a hidden folder so people can not even have a look at it and browse through them?

Ideally (in my notion of how things would ideally be), there is nothing
to be done manually in that folder. Ideally, deken is a management
interface for the user to install, enable, disable, remove libraries.

But it doesn't do all that, for instance, it doesn't delete/remove libraries. And maybe it doesn't have to. Why does it have to do everything, if there are many things you can easily do manually, like a simple thing such as delete a folder. What would be the advantage of hiding it and having a framework to do it for you?

And if you want to have a hidden folder if you wish, you can. Just configure Pd and deken to use a hidden folder of your choice. It's just that there is nothing special about ~/Library/Pd, it's quite arbitrary...

And anyway, what came out of an old discussion is that we should indeed have a new and visible folder for externals. Hence ~/Documents/Pd, a visible and easily accessible folder, instead of ~/Library/Pd, an inconvenient hidden one. Again, this solved all the issues. We've been through all that before. Same concern about Pd not adding ~/Documents/Pd automatically was solved by now prompting the user when it is first launched, and then creates it for you.

So why are we giving this step back? Why are we concerned in making it easier to manage that hidden folder that Pd doesn't create for you? What is special about it? If we're going for friendliness, my point was not that we should avoid, by principle, hidden folders, it was just that this had already been sorted and we do have a new, better, and user friendly procedure since 0.48-0! Doing this now only adds up complexity and confusion, and it isn't even a full solution. Ok, so now you can at least create the folder, but how can you access it? If we're going to that direction, maybe deken should open that folder too for us...

There's no point in trying to fix something that has been already fixed again in a different way. And please understand that I was one that was asking for such a deken feature in the first place, it's just that things have changed and we already have a different outcome.

Unless... unless such a folder is indeed needed and special by design. But it isn't. We've also been through that. I also thought it was supposed to be special, namely an additional "standard path", and that Pd needed and had such standard paths, but it turns out it doesn't! the "standard path" should be only one, the "extra" folder.

So there's really nothing about this that makes sense, as I see it. This is just an ugly kludge, this is just more noise into the system.

You would install a library and this is enables you to simply do [declare -std[path|lib] yourlib] to use it in your patch.

You're using the "-std" prefix, giving the idea we should install in "standard path", and this is also a confusing topic. We shouldn't, we can pretty much, and should, just use -path and -lib.

It looks like we're getting closer to that with all the efforts done recently.

Yes we are, and I don't wanna sound negative, I'm really glad and excited with all the developments. Like I said before, I consider this to be an issue that's beyond deken. It is an issue that affects deken. Until we're all pretty confused about "standard paths" and "paths", and how to use [declare], and which folder should we install our externals too, deken will also be equally confusing. But I hope we can take this opportunity and sort this out once and for all and get rid of the kludge.

cheers