[PD] [PD-announce] deken v0.3.0: new fileformat for library packages

Alexandre Torres Porres porres at gmail.com
Thu Mar 8 22:33:58 CET 2018


2018-03-08 17:44 GMT-03:00 Roman Haefeli <reduzent at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20180308/4b3c02fd/attachment.html>


More information about the Pd-list mailing list