[PD] deken and windows

[Alexandre Torres Porres]

2017-02-17 4:47 GMT-02:00 Lucas Cordiviola <lucarda27 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20170217/e1fd492b/attachment-0001.html>