2017-02-17 2:55 GMT-02:00 Alexandre Torres Porres porres@gmail.com:

it's funny, cause I usually install (and prefer to) in the extra folder of the Pd app (Pd/Contents/Resources/extra).

It's also funny that deken always offers to install in ~/Library/Pd but you can never set it to somewhere else, like in the app as I like. Maybe it could remember last time I asked it to download and so next time it asks it would ask you if you still want in that same place...

2017-02-17 2:55 GMT-02:00 Alexandre Torres Porres porres@gmail.com:

...

next time deken should offer you that dir.

but it doesn't! So i got a bug here I guess...

so, even if I change to somewhere I want, it keeps asking back in the place that it is set to... and in this case it is choosing this folder that I can't write to...

I wonder why I got a different default folder, if it is not supposed to be it, it is a bug...

and besides the bug, I also have this discussion/request on it being able to remember where I like putting my externals...

and, yeah, we could update that web page...

well, I'm too busy right now with something else, will get back to this next week :)

cheers

2017-02-17 4:47 GMT-02:00 Lucas Cordiviola lucarda27@hotmail.com:

Wait a second.

You have Pd-extended & Pd 0.47.1 both installed on the “C:\Program Files (x86)\” ?

Yes, and also Purr Data by the way.

Don't exactly remember the install process, but that's because I didn't do anything creative, just went with the flow, and the 3 of them turned up in this folder...

you can give “write access” to your running “extra” folder

so i did it, and now deken asks me, by default, if I want to install it in "C:/Program Files (x86)/Pd/extra" and I can finally download it there.

2017-02-17 7:34 GMT-02:00 IOhannes m zmölnig zmoelnig@iem.at:

On 02/17/2017 05:55 AM, Alexandre Torres Porres wrote:

...

...

next time deken should offer you that dir.

but it doesn't! So i got a bug here I guess...

pretty sure you didn't.

yeah, I didn't get I had to create a folder myself so deken would then ask me to install it there... and such information on how to proceed is not available anywhere, so it seems...

what deken does *not* do, is to automatically create any of the standard

search paths for you (in case they don't exist). this has been discussed at great lengths on this very list, and i don't think that this will change.

Well, I missed the discussion then, as I wasn't using windows. But now that I'm trying it, I have to say the process is very confusing and could surely be improved.

I raised the issue of providing an information on how to proceed, but I still think it's "hacky" and clumsy if we have to tell users they have to create that folder themselves. If deken looks for a folder that is not there, maybe the Pd installer could create that folder, simple as that. I can see github desktop found its way in creating a folder there, nothing that Pd couldn't do it as well, and then there'd be no need to create a documentation telling users they have to create the folder themselves so deken can find it...

it seems that none of the stdpaths exist on your system (apart from

PDPATH\extra, which is not writable; it is not writeable because of your system's policy, not because of Pd).

Sure, but isn't Pd's fault that the other stdpath wasn't created? And say that it had created... a good documentation would come in hand right here, telling users they also have this other option to download externals, and how they can modify it in the system so it is writeable, like Lucas showed me how to.

oh, and Pd does remembers your decision during the runtime of the

process (it doesn't remember it across restarts)

sure, but I wish it could remember my decision across restarts, so users can decide what's the best option for them and keep it there. The path you enter to download externals could be saved as a preference, and if you change it then the preference gets edited to that new option. Seems convenient, has anybody suggested this before, has that been discussed?

cheers

On 02/17/2017 05:19 PM, Alexandre Torres Porres wrote:

Well, I missed the discussion then, as I wasn't using windows.

the discussion was about deken and creating search paths, not about windows. the behaviour is the same on all platforms.

But now that I'm trying it, I have to say the process is very confusing and could surely be improved.

I raised the issue of providing an information on how to proceed, but I still think it's "hacky" and clumsy if we have to tell users they have to create that folder themselves. If deken looks for a folder that is not there, maybe the Pd installer could create that folder, simple as that. I can see github desktop found its way in creating a folder there, nothing that Pd couldn't do it as well, and then there'd be no need to create a documentation telling users they have to create the folder themselves so deken can find it...

[...]

...

Sure, but isn't Pd's fault that the other stdpath wasn't created?

please check the archives for the discussion on (not) automatically creating those paths.

it's trivial to create those folders (deken did that in the past), but it has been consciously disabled. i would like to avoid going through that discussion *again*.

oh, and Pd does remembers your decision during the runtime of the

...

process (it doesn't remember it across restarts)

sure, but I wish it could remember my decision across restarts

please file a feature request at the deken project on github. i'm pretty sure that it has a good chance of getting implemented.

gfmadsr IOhannes

Hi Roman,

Oh, I am definitely going to challenge that notion. I am totally

convinced the _correct_ way for th....

Sorry, since the topic came up, I had to express what ....

I understand your point and you're right. But remember that those places where is safe to install externals are related to how Pd auto finds them.

Probably a convenient solution has direct connection to Miller's announcement on a prefs. file that currently does not exist for Windows & Mac.

I think that the config file is something that's becoming a “Must” .

Mensaje telepatico asistido por maquinas.

Well you are right.

All the startup flags can be used to do your own config file in a batch.

But for example in the config file there could be a deken dir. So here we do 2 things, Set the any/user/friendly/path for externals and add it to Pd search path.

Also by doing that, some auto-search can be excluded and there are less “file not found, next in the?” All %appdata% %useprofile% are avoided.

You can say is a bit redundant, but a config file is more user friendly, and more flexible than the windows registry.

There were reports on windows that preferences get lost. This is most likely a win.registry.shi*, and it takes time to prepare again all that you did using Pds preference, path, lib, etc.

Alex, Roman, and Dan also mentioned the OSX troubles.

Also we can do different startups by selecting which config file to use. Or by simply manually changing its name.

Mensaje telepatico asistido por maquinas.

From: Pd-list pd-list-bounces@lists.iem.at on behalf of zmoelnig@iem.at zmoelnig@iem.at Sent: Friday, February 17, 2017 10:12 PM To: pd-list@lists.iem.at Subject: Re: [PD] deken and windows

On 02/17/2017 11:07 PM, Lucas Cordiviola wrote:

I think that the config file is something that's becoming a “Must” .

don't we have config "files" on all platforms? (on w32 it is hidden in the registry, but i don't see anything that couldn't be configured there as well).

but the more important question is: what is the configuration file going to solve and how? (esp. what changes to the configuration file do you envision that will make these things possible?)

gfasd IOhannes

2017-02-17 18:51 GMT-02:00 IOhannes m zmölnig zmoelnig@iem.at:

check the archives for the discussion on (not) automatically creating those paths (...) i would like to avoid going through that discussion *again*.

I could use some help like pointing me a thread subject or something, I usually never find discussions I want and been part of in the archives...

please file a feature request at the deken project

done https://github.com/pure-data/deken/issues/140

Oh, I am definitely going to challenge that notion. I am totally

convinced the _correct_ way for the user-specific folder is to be created automatically at some point.

not shockingly, I totally agree... The current situation is just totally absurd indeed and I just wanted to stress it.

From what I remember, people objected to the auto-creation of ~/pd- externals directory. Yes, I, too, find it rogue to create visible folders directly in the user home without asking.

Was that really it? and why is it "rogue" to create a folder Pd needs as the standard? I can't make sense out of this...

I vaguely remember that people didn't want a pre-established way, because they thought that workflows are so diverse that deken shouldn't enforce one specific workflow.

But that it's exactly what it is doing right now! It always asks for the SAME folder *every time* you start Pd... which is _never_ the one I use. So if that was the reasoning, then this seems to have been in vain... and how about this issue I had with windows? Where it's forcing a workflow that doesn't work out of the box unless there is some workaround...

Deviating workflows wouldn't be harmed at all by auto-creation of the user specific standard directory.

It would actually have solve my issue in windows...

cheers

2017-02-17 19:27 GMT-02:00 Roman Haefeli reduzent@gmail.com:

On Fre, 2017-02-17 at 21:51 +0100, IOhannes m zmölnig wrote:

...

it's trivial to create those folders (deken did that in the past), but it has been consciously disabled.

I disagree. I don't find it a conscious decision.

...

i would like to avoid going through that discussion *again*.

Sorry, since the topic came up, I had to express what I was thinking for quite some time. While I understand your rejection to discuss the same topic several times, good progress often needs several attempts.

Roman _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list

On Fre, 2017-02-17 at 10:34 +0100, IOhannes m zmölnig wrote:

what deken does *not* do, is to automatically create any of the standard search paths for you (in case they don't exist). this has been discussed at great lengths on this very list, and i don't think that this will change.

Oh, I am definitely going to challenge that notion. I am totally convinced the _correct_ way for the user-specific folder is to be created automatically at some point. I don't know if it should be done by deken (the plugin) or Pd and I don't care too much. The current situation, however, is just totally absurd. Whenever I install Pd on a new machine, I need to go visit Deken's README first on github.com to find out the user specific path for the particular platform. Last time I helped someone on a Mac by giving directions without using a terminal, I figured there is no sane way without terminal (some people create symlinks to have Finder access to ~/Library). Also on Windows, you need to know sysadmin stuff (-> %AppData%) before you can create the directory.

Why is that stuff hidden by the OS? Because applications normally create their own folders there _A_U_T_O_M_A_T_I_C_A_L_L_Y_! The user is _not_ supposed to go there.

From what I remember, people objected to the auto-creation of ~/pd- externals directory. Yes, I, too, find it rogue to create visible folders directly in the user home without asking. But Pd has progressed and does use _sane_ paths now and nicely adheres to the platform specific standards. But why, oh why does it _not_ create the necessary directories when the standard is exactly that required directories are auto-created by the application?

Pd's refusal to automatically create that directory where 99% of the users need it is hypocritical, since it does already auto-create ~/.pdsettings (or even writes to the registry). Why not also create the directory for installing externals? Do you want Pd to ask for a location before you can save changes in the preferences dialog, just to confuse the user and make sure that Pd won't read the settings file because the uninformed user will use some random location and filename, just not the _only_ right combination that guarantees consideration by Pd? How do people who object to auto-creation expect newcomers to do things correctly without any hint from Pd? Standard

I vaguely remember that people didn't want a pre-established way, because they thought that workflows are so diverse that deken shouldn't enforce one specific workflow. I still do not believe this is a valid argument. Deken asks you every time you install something for the installation path. You can always manually change the installation path. Deviating workflows wouldn't be harmed at all by auto-creation of the user specific standard directory. Also, I don't see why we should care so much about a handful of experts that may use several versions of Pd installed in their home directory. First, things should be made easy for the masses (I count myself to the masses, I deliberately install things like the most common user would do it, since usually I want my stuff to work in standard installations).

</rant>

# sorry if I come off as grumpy, I'm not at all, I'm enthusiastic about how things got better with Deken. It's just that such tiny things stick out so far that they really hurt...

Roman