how-do-i-install-externals-and-help-files page (was Re: Linux Global folder for externals)
2017-03-01 12:48 GMT-03:00 IOhannes m zmoelnig zmoelnig@iem.at:
thanks for bringing this to up. i've removed the offending line and updated the "User-specific" part of the linux section.
but of course the page needs even more love.
I got all my love to give... let's work on this then https://puredata.info/docs/faq/how-do-i-install-externals-and-help-files?por... .
So... how about "application specific" folder (the "extra" folder)? I think that's important to include. It's what I prefer anyway... I had included it but you removed, can I put back? If not, how come?
for windows, you have
- %AppData%\Pd will be something like C:\Documents and
Settings\myusername\AppData\Roaming\Pd
But seems wrong, I have here ob my machine: *C:\Users\myusername\AppData\Roaming\Pd*
Now, a question... about
User-specific~/.local/lib/pd/extra (since Pd-0.47-1, *preferred*)User-specific (deprecated)~/pd-externals (older Pd-versions; still usable)
why is this new form preferred?
cheers
for windows, you have
* %AppData%\Pd will be something like C:\Documents and Settings\myusername\AppData\Roaming\Pd
But seems wrong, I have here ob my machine: C:\Users\myusername\AppData\Roaming\Pd
"C:\Users\myus..." is correct I updated it.
Mensaje telepatico asistido por maquinas.
On 03/01/2017 05:03 PM, Alexandre Torres Porres wrote:
So... how about "application specific" folder (the "extra" folder)? I think that's important to include. It's what I prefer anyway... I had included it but you removed, can I put back? If not, how come?
it was not included on the page i edited. i didn't remove it.
for windows, you have
- %AppData%\Pd will be something like C:\Documents and
Settings\myusername\AppData\Roaming\Pd
But seems wrong, I have here ob my machine: *C:\Users\myusername\AppData\Roaming\Pd*
that's why the "something like" comes into play. the actual storage place *can change* between windows-versions, but %AppData% is where it ought to be. the percent-signs indicate that this is an environment variable. (W32 uses variables supposedly *because* the actual storage place changes)
Now, a question... about
User-specific~/.local/lib/pd/extra (since Pd-0.47-1, *preferred*)User-specific (deprecated)~/pd-externals (older Pd-versions; still usable)
why is this new form preferred?
you know, i keep repeating myself: because it has been discussed and agreed on on this very list. it's great that you are questioning a lot of things in Pd, but in generally it would help if you would also read the email of others that are not of current concern to yourself. because they may hold the answers to questions you haven't yet asked.
to answer you question more specifically: because ~/.local/lib/ is the standard (as defined by freedesktop specs) place on linux systems to put application specific data. very much like ~/Library/ is the standard (as defined by apple inc) place for those kind of things on OSX. and very much like %AppData% is the standard (as defined by microsoft corp) place for those kind of things on W32.
gadsr IOhannes
2017-03-01 17:17 GMT-03:00 IOhannes m zmölnig zmoelnig@iem.at:
On 03/01/2017 05:03 PM, Alexandre Torres Porres wrote:
So... how about "application specific" folder (the "extra" folder)? I
think
that's important to include. It's what I prefer anyway... I had included
it
but you removed, can I put back? If not, how come?
it was not included on the page i edited. i didn't remove it.
Oh, it's cause I had included it, anyway, I'm including it again then, ok? BTW, what you're calling package manager is the application specific folder
cheers
On 03/01/2017 09:31 PM, Alexandre Torres Porres wrote:
BTW, what you're calling package manager is the application specific folder
no not really (well, half-true).
the application-specific folder can be a number of things. it will only be /usr/lib/pd/extra, if Pd is installed into /usr (that is /usr/bin and /usr/lib/, as opposed to e.g. /usr/local/{bin/lib}).
it get's even more complicated, when dealing with different flavours of Pd. the original draft [1] we came up with, which would allow (binary) compatible Pd-flavours to co-exist and share the same package-manager installed libraries was: Debian's "puredata" package's application specific folder is /usr/lib/puredata/extra, but it *also* searches /usr/lib/pd/extra. the former is meant for binaries that are not "compatible" with other flavours. the latter would be searched by flavours like Pd-extended. with the demise of PdX this has become somewhat obsolet (with current Pd-flavours like Pd-l2ork actively refusing any notion of compatibility, and rather investing time into re-packaging everything from scratch), but there you go.
dfsnra IOhannes
[1] https://lists.puredata.info/pipermail/pd-dev/2010-06/015407.html
On 2017-03-01 21:31, Alexandre Torres Porres wrote:
Oh, it's cause I had included it, anyway, I'm including it again then, ok?
i'm not opposed to that, but I think we should **not** recommend users
to make system-directories (such as %ProgramFiles(x86)%\Pd\extra or
/Applications/Pd-0.47-1/Contents/Resources/extra) to be made
*writable* by everyone.
there is a reason why such folders are not writable by everybody: security.
fgmasdr IOhannes
2017-03-01 17:17 GMT-03:00 IOhannes m zmölnig zmoelnig@iem.at:
On 03/01/2017 05:03 PM, Alexandre Torres Porres wrote:
User-specific~/.local/lib/pd/extra (since Pd-0.47-1,
*preferred*)User-specific
(deprecated)~/pd-externals (older Pd-versions; still usable)
you all might be aware, but you that deken still installs it in the deprecated '~/pd-externals' path?
On 03/01/2017 09:47 PM, Alexandre Torres Porres wrote:
you all might be aware, but you that deken still installs it in the deprecated '~/pd-externals' path?
no, deken installs into the first available (and writeable) folder. it first checks whether there is a ~/.local/lib/pd/extra folder, and if there is it will suggest to install there. if that folder does not exist (or is not writable), it will try ~/pd-externals. and so on.
actually, it doesn't know anything about ~/.local/lib/pd/extra or the like. it just uses the search paths of Pd. (so if you are using deken with Pd-0.45, it will not even try ~/.local/lib/pd/extra)
fun fact: it seems i already explained that recently. e.g. https://lists.puredata.info/pipermail/pd-list/2017-02/117965.html
gfmards IOhannes
2017-03-01 19:07 GMT-03:00 zmoelnig@iem.at:
On 03/01/2017 09:47 PM, Alexandre Torres Porres wrote:
you all might be aware, but you that deken still installs it in the deprecated '~/pd-externals' path?
no, deken installs into the first available (and writeable) folder. it first checks whether there is a ~/.local/lib/pd/extra folder, and if there is it will suggest to install there. if that folder does not exist (or is not writable), it will try ~/pd-externals. and so on.
this is then related to another previous discussion, but on windows, where we ended up discussing that Pd should install these folders automatically...
On Mit, 2017-03-01 at 19:37 -0300, Alexandre Torres Porres wrote:
2017-03-01 19:07 GMT-03:00 zmoelnig@iem.at:
On 03/01/2017 09:47 PM, Alexandre Torres Porres wrote:
you all might be aware, but you that deken still installs it in
the
deprecated '~/pd-externals' path?
no, deken installs into the first available (and writeable) folder. it first checks whether there is a ~/.local/lib/pd/extra folder, and if there is it will suggest to install there. if that folder does not exist (or is not writable), it will try ~/pd-externals. and so on.
this is then related to another previous discussion, but on windows, where we ended up discussing that Pd should install these folders automatically...
I don't think that was the conclusion. Why should be the user-specific search path auto-created only on Windows?
IOhannes made it sound like there was an agreement that the user- specific folders should not be auto-created _anywhere_. I'm still convinced that this decision is detrimental for larger part of Pd end users.
I'm currently wondering if there are people who actively defend the current behavior of Pd/Deken. We didn't hear many voices. IOhannes said it has been discussed and the decision is definitive. I think that you, Alex, are with me in believing the current situation is unfortunate and it would be helpful for many if users if they don't have to hunt down what (hidden) directory they have to create before they can use Deken in a meaningful manner.
Maybe we can up with a way that everybody agrees on? If people don't want to have or use the platform specific user specific folder, it shouldn't be created for them. I think this excludes Pd from auto- creating whenever it runs. So it probably would be best if Deken deals with that issue. Deken already asks people where they want to install stuff and it proposes the first writable (by the current user) folder and falls back to $HOME, if no user-writable standard search path is found. However, $HOME is not a standard search path.
Proposal:
First time Deken is used, it asks to install to the user specific folder regardless whether it exists. If the user confirms, it automatically creates it and download/extracts the installed external there. If the user says "no" the first time, Deken remembers this decision and doesn't prompt for the user specific folder anymore from then on as long as it does not exist. We would then have the same behavior as we do have now.
pros: * People do not have to know about Pd peculiarities before they can successfully install and use external. * Nobody is forced to use the user specific folder if they don't want to.
cons: * People that do not want to use the user specific folder have to click 'no' once. Is that too demanding? * Deken needs some way to remember the decision. I don't know if Deken has already a notion of remembering user decisions. I hope it does.
End goal:
The required knowledge to use externals successfully boils down to: * selecting an external in Deken * [declare] it within the patch
What do you think?
Roman
On 2017-03-02 11:42, Roman Haefeli wrote:
Proposal:
First time Deken is used, it asks to install to the user specific folder regardless whether it exists. If the user confirms, it automatically creates it and download/extracts the installed external there. If the user says "no" the first time, Deken remembers this decision and doesn't prompt for the user specific folder anymore from then on as long as it does not exist. We would then have the same behavior as we do have now.
pros:
- People do not have to know about Pd peculiarities before they can successfully install and use external.
- Nobody is forced to use the user specific folder if they don't want to.
cons:
- People that do not want to use the user specific folder have to click 'no' once. Is that too demanding?
- Deken needs some way to remember the decision. I don't know if Deken has already a notion of remembering user decisions. I hope it does.
End goal:
The required knowledge to use externals successfully boils down to:
- selecting an external in Deken
- [declare] it within the patch
What do you think?
rather than remembering the decision whether the user does (not) want the proposed directory, i'd rather have deken remember the last used install path. from the user side this seems to be more what we really want (if the user chose to not install into the default location, they must provide an alternative anyhow; chances are that they want to use it again; if not they have to (and can) select a different location.
from the implementation side it doesn't really matter whether we need to store a single flag or a full path.
https://github.com/pure-data/deken/issues/140
fgmasdr IOhannes
On Don, 2017-03-02 at 14:47 +0100, IOhannes m zmoelnig wrote:
On 2017-03-02 11:42, Roman Haefeli wrote:
Proposal:
First time Deken is used, it asks to install to the user specific folder regardless whether it exists. If the user confirms, it automatically creates it and download/extracts the installed external there. If the user says "no" the first time, Deken remembers this decision and doesn't prompt for the user specific folder anymore from then on as long as it does not exist. We would then have the same behavior as we do have now.
pros: * People do not have to know about Pd peculiarities before they can successfully install and use external. * Nobody is forced to use the user specific folder if they don't want to.
cons: * People that do not want to use the user specific folder have to click 'no' once. Is that too demanding? * Deken needs some way to remember the decision. I don't know if Deken has already a notion of remembering user decisions. I hope it does.
End goal:
The required knowledge to use externals successfully boils down to: * selecting an external in Deken * [declare] it within the patch
What do you think?
rather than remembering the decision whether the user does (not) want the proposed directory, i'd rather have deken remember the last used install path. from the user side this seems to be more what we really want (if the user chose to not install into the default location, they must provide an alternative anyhow; chances are that they want to use it again; if not they have to (and can) select a different location.
Good point.
from the implementation side it doesn't really matter whether we need to store a single flag or a full path.
Glad to hear.
What about prompting for the user specific folder, even if does not exist, and creating it when confirmed? Do you, too, think this would be desirable? Should I open another issue for this?
Roman
On 2017-03-02 15:11, Roman Haefeli wrote:
On Don, 2017-03-02 at 14:47 +0100, IOhannes m zmoelnig wrote:
What about prompting for the user specific folder, even if does not exist, and creating it when confirmed? Do you, too, think this would be desirable? Should I open another issue for this?
this is probably a solution that makes both parties (those that want directories to be autocreated, and those that don't) happy.
please open another issue.
fgmasdr IOhannes
On Don, 2017-03-02 at 15:38 +0100, IOhannes m zmoelnig wrote:
On 2017-03-02 15:11, Roman Haefeli wrote:
On Don, 2017-03-02 at 14:47 +0100, IOhannes m zmoelnig wrote:
What about prompting for the user specific folder, even if does not exist, and creating it when confirmed? Do you, too, think this would be desirable? Should I open another issue for this?
this is probably a solution that makes both parties (those that want directories to be autocreated, and those that don't) happy.
please open another issue.
I did:
https://github.com/pure-data/deken/issues/143
Thanks for consideration Roman
2017-03-02 7:42 GMT-03:00 Roman Haefeli reduzent@gmail.com:
I don't think that was the conclusion. Why should be the user-specific search path auto-created only on Windows?
Oh, it's not only on windows... not what I meant.
If I'm not mistaken, it seems that in MAC OS this is somehow created (am I right? Maybe not... help please)... anyway, I did realize that in windows it wasn't created and that started that older discussion, but now I see it doesn't also create for linux...
I think that you, Alex, are with me in believing the current situation is
unfortunate
totally, and besides user specific folders, I also think *Global folders* should be created as well... and it seems that they're not created in *any* of the platforms. Anyway, this is why, yesterday, I did in fact create a ticket about it, see it here: https://sourceforge.net/p/pure-data/bugs/1287/
Proposal:
First time Deken is used, it asks to install to the user specific folder regardless whether it exists. If the user confirms, it automatically creates it and download/extracts the installed external there. If the user says "no" the first time, Deken remembers this decision and doesn't prompt for the user specific folder anymore from then on as long as it does not exist.
nah, I think this is bad, you're considering that people are consciously doing something, which is not the case...
pros:
- People do not have to know about Pd peculiarities before they can successfully install and use external.
actually they do... they need to know that it is a peculiarity that Pd has a Standard Path which is not created (which is more of a countersense to me than a peculiarity - the oficial folder is hidden and not created, and we need to know and create it ourselves if we want to...) and not only that, but also know that their first decision may prevent that folder to be created. So they not only need to know about this peculiarity, but they need to know more!
2017-03-02 11:38 GMT-03:00 IOhannes m zmoelnig zmoelnig@iem.at:
On 2017-03-02 15:11, Roman Haefeli wrote:
On Don, 2017-03-02 at 14:47 +0100, IOhannes m zmoelnig wrote:
What about prompting for the user specific folder, even if does not exist, and creating it when confirmed? Do you, too, think this would be desirable? Should I open another issue for this?
this is probably a solution that makes both parties (those that want directories to be autocreated, and those that don't) happy.
So what happens if I didn't choose the user specific folder in the first time? If I want then to do it later, I'll have to create the folder manually, and then ask deken to download it there, and it's quite tricky cause these folders aren't really easily accessible - I might need to create ugly simlinks on top of everything - anyway, it's still very peculiar...
I'm still to hear what's bad about creating such folders automatically when installing and running Pd for the first time...
but I don't care really when they are created or not, if it comes down to the deken plug-in doing the job, I don't care. But this still doesn't really solve the issues...
UNLESS... unless deken has these options very clear and easily accessible. It actually makes a lot of sense that deken offers us these system folders quite easily as a preset. In a drop menu or something, we could chose: a) Global b) User-specific c) Application-specific d) Other (opening up the 'openpanel' so one can navigate and choose wherever/whatever is desired).
Combine this idea with the other one, where deken remembers and asks for the last chosen path until you tell it to choose something else, and then it'll prompt you for those options again...
Now, wether these (Globel/User) are created by deken or not, I don't care and don't wanna make a case of it, though I think it makes more sense that these folders are created automatically outside 'deken' - but if the idea is that it's 'deken' that creates the folders, I'm not really asking for anything new... I'm just proposing something that makes it really easier for the end user.
Another thing is to have a good and proper documentation available somewhere easy to find, so the user can learn about the difference between these options. This is related to another thread here, where I'm doing that myself. I'm hoping to provide a very extensive, detailed, clear and straightforward documentation on how to (and where to) download and load externals.
cheers
On 03/02/2017 08:10 PM, Alexandre Torres Porres wrote:
If I'm not mistaken, it seems that in MAC OS this is somehow created (am I right? Maybe not... help please)... anyway, I did realize that in windows it wasn't created and that started that older discussion, but now I see it doesn't also create for linux...
no folders are created on any platform.
(Pd-extended used to create folders. luckily this has been disabled with Pd-vanilla.)
gfards IOhannes
2017-03-02 16:15 GMT-03:00 IOhannes m zmölnig zmoelnig@iem.at:
no folders are created on any platform.
(Pd-extended used to create folders. luckily this has been disabled with Pd-vanilla.)
Oh, I see, so I have the user specific folder here because I have Pd-extended! Mystery solved, thanks.
Now, why do you think this was luckily disabled? Me and Roman have shared our thoughts why this seems unfortunate, what do you have to add?
2017-03-02 11:58 GMT-03:00 Roman Haefeli reduzent@gmail.com:
Hey, I also added another request, about offering the Standard Paths:
https://github.com/pure-data/deken/issues/144
cheers
2017-03-01 19:07 GMT-03:00 zmoelnig@iem.at:
there is it will suggest to install there. if that folder does not exist (or is not writable), it will try ~/pd-externals. and so on.
so, the order deken searches seem to be: user-specific, global, application-specific
since the suer/global folders aren't created (anymore), application is usually the first and only option. Now, in windows, that folder is not writeable... so deken cannot offer anything that'll work right away.
But the thing is that it prompts you for downloading to this folder which is not writeable anyway... even though it will fail.
So I wonder and ask if it really skips an option if the folder is not writeable.
cheers
On Don, 2017-03-02 at 16:43 -0300, Alexandre Torres Porres wrote:
2017-03-01 19:07 GMT-03:00 zmoelnig@iem.at:
there is it will suggest to install there. if that folder does not exist (or is not writable), it will try ~/pd-externals. and so on.
so, the order deken searches seem to be: user-specific, global, application-specific
since the suer/global folders aren't created (anymore),
From what I remember, they have never been auto-created. And it wasn't an issue at all before Deken, since you either installed something through package manager, which creates all necessary directories, or you compiled something yourself and usually installed it with something like 'make install', which took care of the necessary directories, too.
Only since Deken exists, it's a question who or what creates those folders.
application is usually the first and only option. Now, in windows, that folder is not writeable... so deken cannot offer anything that'll work right away.
That's true. I thought that was unfortunate and I you agreed with me. I opened ticked [1] for Deken, so that Deken prompts you whether you want to install to the user specific folder and creates it on confirmation. IOhannes already went ahead and implemented it. :-)
I think that is quite an achievement (although the actual commit is pretty small). Thanks a lot, IOhannes.
But the thing is that it prompts you for downloading to this folder which is not writeable anyway... even though it will fail.
So I wonder and ask if it really skips an option if the folder is not writeable.
From what I understand, Deken prompts you only for directories where the user as write permissions for. If you gave yourself write privileges to the application specific or global search paths, yes, then Deken will ask to install there, if it doesn't find a user specific folder.
2017-03-02 17:20 GMT-03:00 Roman Haefeli reduzent@gmail.com:
since the suer/global folders aren't created (anymore),
From what I remember, they have never been auto-created.
the user folder is created by extended
And it wasn't an issue at all before Deken, since you either installed something through package manager, which creates all necessary directories, or you compiled something yourself and usually installed it with something like 'make install', which took care of the necessary directories, too. Only since Deken exists, it's a question who or what creates those
folders.
yeah, but not everybody uses linux, and being a mac user myself, I never had to use a package manager or compile stuff.
I opened ticked [1] for Deken, so that Deken prompts you whether you want to install to the user specific folder and creates it on confirmation. IOhannes already went ahead and implemented it. :-)
wow, that's awesome, I had missed it, thanks a lot indeed <3
But the thing is that it prompts you for downloading to this folder
which is not writeable anyway... even though it will fail.
So I wonder and ask if it really skips an option if the folder is not
writeable.
You mean in linux, right?
Yeah, that's what was happening in windows, it was asking to download to the application, and failing it. When I brought it up, the reasoning was that this is the operating system's fault, not Pd's.
And while it may not be possible for linux, it works just fine in Mac Os and Windows... so, well, deal with your operating system I guess?
In windows, all I had to do was to edit the folder's permissions to make it writeable, then deken could download it to the application folder as I wanted.
From what I understand, Deken prompts you only for directories where the user as write permissions for.
If you gave yourself write
privileges to the application specific or global search paths, yes, then Deken will ask to install there, if it doesn't find a user specific folder.
As I mentioned in a previous message here, it prompts you in windows to write in the application folder even if it is not writeable, and even if it fails if you ask it to download there. Maybe it skips but eventually prompts it as a last resource? I don't know...
cheers
On 03/02/2017 09:51 PM, Alexandre Torres Porres wrote:
As I mentioned in a previous message here, it prompts you in windows to write in the application folder even if it is not writeable, and even if it fails if you ask it to download there. Maybe it skips but eventually prompts it as a last resource? I don't know...
yes, most likely.
gfds IOhannes
On Don, 2017-03-02 at 17:51 -0300, Alexandre Torres Porres wrote:
2017-03-02 17:20 GMT-03:00 Roman Haefeli reduzent@gmail.com:
since the suer/global folders aren't created (anymore),
From what I remember, they have never been auto-created.
the user folder is created by extended
Sorry, you're right. Pd-vanilla never did create any folders, though.
I opened ticked [1] for Deken, so that Deken prompts you whether you want to install to the user specific folder and creates it on confirmation. IOhannes already went ahead and implemented it. :-)
wow, that's awesome, I had missed it, thanks a lot indeed <3
Let's thank IOhannes that he was still willing to cooperate after all this nagging... ;-)
Yes, I, too, am delighted.
But the thing is that it prompts you for downloading to this
folder
which is not writeable anyway... even though it will fail.
So I wonder and ask if it really skips an option if the folder is
not
writeable.
You mean in linux, right?
I'm confused. You wrote above sentence. Don't know what you meant.
Yeah, that's what was happening in windows, it was asking to download to the application, and failing it. When I brought it up, the reasoning was that this is the operating system's fault, not Pd's.
Don't know what happened there. Deken should not ask you to download there, if it can't write there. If it still does, it might be a bug.
If you think you found a bug, please be very specific about what you did and what defaults you changed in your system.
And while it may not be possible for linux,
If I give myself privileges to write to /usr/lib/pd/extra and there is no ~/.local/lib/pd/extra, I believe Deken would ask me to install there, also on Linux.
it works just fine in Mac Os and Windows... so, well, deal with your operating system I guess?
In windows, all I had to do was to edit the folder's permissions to make it writeable,
IOhannes already pointed out that you're not supposed to do that. Users don't write there for security reasons. That's why they have their user specific folder. Anyway, at least don't teach that to anybody, even if you believe it works well for you.
Roman
2017-03-02 18:08 GMT-03:00 Roman Haefeli reduzent@gmail.com:
I'm confused. You wrote above sentence. Don't know what you meant.
haha, I'm even arguing to myself then! It's that on the deken issue you were complaining about not being able to write to the user folder... I was trying to say that was a linux issue only.
Deken should not ask you to download there, if it can't write there. If it still does, it might be a bug.
it's just a last ditch effort, it's gotta ask you to download somewhere...
That's why they have their user specific folder.
Well, they don't for Pd... at least for now...
Anyway, at least don't teach that to anybody, even if you believe it works well for you.
It has a particularity... it makes a difference wether you install in the global, user or application. In the case of an application, it'll only be valid for that Pd app, so you can have multiple Pds or Pd-Extended along side it. So, well, yeah, I think we should tell people that they can do it if they want to...
you're not supposed to do that. Users don't write there for security
reasons.
ok, maybe warn people... but it doesn't seem too dangerous anyway, more of an annoyance. I mean, I never knew other operating systems had issues with it, I could always do it in Mac OS and always have...
cheers
2017-03-02 18:26 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
I never knew other operating systems had issues with it, I could always do it in Mac OS and always have...
For the record, Mac OS allows you to write in any of the 3 Standard Paths, application-specific, user-specific and global.
Being a Mac user I just took it for granted...
I'm actually amazed there are all these issues elsewhere... didn't realize how tricky installing externals could be.
cheers
On Don, 2017-03-02 at 18:26 -0300, Alexandre Torres Porres wrote:
2017-03-02 18:08 GMT-03:00 Roman Haefeli reduzent@gmail.com:
I'm confused. You wrote above sentence. Don't know what you meant.
haha, I'm even arguing to myself then! It's that on the deken issue you were complaining about not being able to write to the user folder... I was trying to say that was a linux issue only.
Deken should not ask you to download there, if it can't write there. If it still does, it might be a bug.
it's just a last ditch effort, it's gotta ask you to download somewhere...
That's why they have their user specific folder.
Well, they don't for Pd... at least for now...
Anyway, at least don't teach that to anybody, even if you believe it works well for you.
It has a particularity... it makes a difference wether you install in the global, user or application. In the case of an application, it'll only be valid for that Pd app, so you can have multiple Pds or Pd- Extended along side it. So, well, yeah, I think we should tell people that they can do it if they want to...
Sorry if I didn't make myself clear. It's not advised to change the default permissions of protected system-wide folders. There's nothing wrong with hand-crafting your Pd.app to suite your specific needs.
Roman
On 03/02/2017 10:26 PM, Alexandre Torres Porres wrote:
2017-03-02 18:08 GMT-03:00 Roman Haefeli reduzent@gmail.com:
Deken should not ask you to download there, if it can't write there. If it still does, it might be a bug.
it's just a last ditch effort, it's gotta ask you to download somewhere...
by now i think it is rather like this: if deken doesn't find a writable folder, it will just open the directory-browser wherever Pd currently is (in its working-directory). this directory might happen to be writable or not. it is not a suggestion to blindly accept.
That's why they have their user specific folder.
Well, they don't for Pd... at least for now...
well, they do. they just have to create them :-)
Anyway, at least don't teach that to anybody, even if you believe it works well for you.
It has a particularity... it makes a difference wether you install in the global, user or application. In the case of an application, it'll only be valid for that Pd app, so you can have multiple Pds or Pd-Extended along side it. So, well, yeah, I think we should tell people that they can do it if they want to...
i don't think so. take any well-established software that allows you to install addons from the net, e.g. firefox. it *is* possible to install firefox-addons systemwide, but *you cannot* do so via its built-in addon manager.
i'm pretty sure they put some decent thought into that.
you're not supposed to do that. Users don't write there for security
reasons.
ok, maybe warn people... but it doesn't seem too dangerous anyway, more of an annoyance. I mean, I never knew other operating systems had issues with it, I could always do it in Mac OS and always have...
it's not that they have issues. they have *features* (and i mean it)
i suppose you are running OSX as an "admin" user. you can do quite a number of things on the filesystem as "admin" on OSX without being prompted for your password, e.g. if you are brave enough to use the terminal.
gfds IOhannes
2017-03-02 19:25 GMT-03:00 IOhannes m zmölnig zmoelnig@iem.at:
It has a particularity... it makes a difference wether you install in the global, user or application. In the case of an application, it'll only be valid for that Pd app, so you can have multiple Pds or Pd-Extended along side it. So, well, yeah, I think we should tell people that they can do
it
if they want to...
i don't think so. take any well-established software that allows you to install addons from the net, e.g. firefox. it *is* possible to install firefox-addons systemwide, but *you cannot* do so via its built-in addon manager.
i'm pretty sure they put some decent thought into that.
I'm not sure what you're trying to respond to in here. I was just saying how it makes a difference to install in the application folder, am I not right? And the difference is that only that Pd application will see it.
While we're at it, am I right to say that it makes a difference if things are installed in the global or user path? I'm assuming that the global folder affects all Pd applications for all users, then the user folder affects all Pd applications for that user.
i suppose you are running OSX as an "admin" user.
it might be, but it's not a decision, I just bought the machine, turned it on and started using it...
cheers
2017-03-02 17:20 GMT-03:00 Roman Haefeli reduzent@gmail.com:
I opened ticked [1] for Deken, so that Deken prompts you whether you want to install to the user specific folder and creates it on confirmation. IOhannes already went ahead and implemented it. :-)
so, how could we test the new deken? is there a simple download and replace procedure? cause i tried it and failed... :/
On 03/02/2017 11:03 PM, Alexandre Torres Porres wrote:
2017-03-02 17:20 GMT-03:00 Roman Haefeli reduzent@gmail.com:
I opened ticked [1] for Deken, so that Deken prompts you whether you want to install to the user specific folder and creates it on confirmation. IOhannes already went ahead and implemented it. :-)
so, how could we test the new deken? is there a simple download and replace procedure? cause i tried it and failed... :/
for starters, you could just follow the instructions on https://github.com/pure-data/deken/#download
(i would have guessed that after this long thread everybody knows how to install libraries ;-))
fdamrs IOhannes
2017-03-02 19:17 GMT-03:00 IOhannes m zmölnig zmoelnig@iem.at:
for starters, you could just follow the instructions on https://github.com/pure-data/deken/#download
I had done that, but downloading deken-plugin.tcl https://raw.githubusercontent.com/pure-data/deken/master/deken-plugin.tcl to my Pd folder doesn't do it...
and I also tried to replace the pd_deken.tcl file inside the pd app for the new one, no luck...
it load the deken plug in, but it's not asking to download to the user folder even if it is not there (let alone create it) and it's not remembering the path between restarts.
maybe it's not enough to get the new deken code from its github? Maybe I need to recompile Pd when it gets merged?
cheers
On Don, 2017-03-02 at 20:22 -0300, Alexandre Torres Porres wrote:
2017-03-02 19:17 GMT-03:00 IOhannes m zmölnig zmoelnig@iem.at:
for starters, you could just follow the instructions on https://github.com/pure-data/deken/#download
I had done that, but downloading deken-plugin.tcl to my Pd folder doesn't do it...
and I also tried to replace the pd_deken.tcl file inside the pd app for the new one, no luck...
it load the deken plug in, but it's not asking to download to the user folder even if it is not there (let alone create it) and it's not remembering the path between restarts.
maybe it's not enough to get the new deken code from its github? Maybe I need to recompile Pd when it gets merged?
No, you just need to put it into a search path of Pd. If your goal is to test whether the most recent change works (creation of the user specific folder), then you obviously can't use that, you may put it into the application specific folder (don't know the exact path for Mac, something like /Applications/Pd.app/[...]/extra).
Download this file: https://raw.githubusercontent.com/pure-data/deken/master/deken-plugin.tcl
Save it to extra, make sure it has the name deken-plugin.tcl.
That's it. It will override the one included in Pd and it will announce that in the Pd console with a message like:
deken-plugin.tcl (Pd externals search) in /home/roman/.local/lib/pd/extra loaded. Platform detected: Linux-x86_64-64bit
If you such a message, then you are ready to test the new feature. Search something, click something and it should ask you:
"Install to /Users/alexandre/Library/Pd?"
If you click 'yes', this directory is created. As far as I know, the 'remember the last path' feature hasn't been implemented yet.
Roman
2017-03-03 17:32 GMT-03:00 Roman Haefeli reduzent@gmail.com:
No, you just need to put it into a search path of Pd. If your goal is to test whether the most recent change works (creation of the user specific folder), then you obviously can't use that, you may put it into the application specific folder (don't know the exact path for Mac, something like /Applications/Pd.app/[...]/extra).
Download this file: https://raw.githubusercontent.com/pure-data/deken/master/deken-plugin.tcl
Save it to extra, make sure it has the name deken-plugin.tcl.
that didn't woirk, my pd has a pd_deken.tcl file in a tcl folder outside the extra folder, that's the one that needs to be replaced, so it seems...
but if I replace it by the renamed file from the link you're pointing me, well, I get no new behaviour.
and what do you mean I "obviously can't use that"? I can't test the creation of the user specific folder? Then it's pointless :/
As far as I know, the 'remember the last path' feature hasn't been
implemented yet.
Too bad, I also wanted to test that :/
cheers
Hey Alex
On Fre, 2017-03-03 at 18:19 -0300, Alexandre Torres Porres wrote:
2017-03-03 17:32 GMT-03:00 Roman Haefeli reduzent@gmail.com:
No, you just need to put it into a search path of Pd. If your goal is to test whether the most recent change works (creation of the user specific folder), then you obviously can't use that, you may put it into the application specific folder (don't know the exact path for Mac, something like /Applications/Pd.app/[...]/extra).
Download this file: https://raw.githubusercontent.com/pure-data/deken/master/deken-plug in.tcl
Save it to extra, make sure it has the name deken-plugin.tcl.
that didn't woirk, my pd has a pd_deken.tcl file in a tcl folder outside the extra folder, that's the one that needs to be replaced, so it seems...
I'm really trying to be very specific in my instructions. Please follow them as closely as possible.
I said: put it into 'extra/' and name it deken-plugin.tcl. I didn't say "overwrite the internal one, which is called pd_deken.tcl and lives in tcl/". Both can co-exist just fine. The one in extra/ has precedence over the included one.
but if I replace it by the renamed file from the link you're pointing me, well, I get no new behaviour.
Follow my instructions.
and what do you mean I "obviously can't use that"? I can't test the creation of the user specific folder? Then it's pointless :/
Of course you can test that. I'm trying to say that you obviously can't put the deken-plugin.tcl file into $HOME/Library/Pd (which would normally be a sensible location), because you want to test if the new deken-plugin.tcl creates that folder, so I assume it doesn't exist at the beginning of your test. Maybe I was indeed not very clear. Sorry.
Roman
thanks roman for the detailed instructions (and the patience). that's exactly how it's meant to be.
On 03/03/2017 10:36 PM, Roman Haefeli wrote:
Both can co-exist just fine. The one in extra/ has precedence over the included one.
just a small amendment here: the one in extra/ *only* has precedence if it has a greater version number than the one in pd_deken.tcl. so you canNOT downgrade deken by installing an outdated deken-plugin.tcl
gasmdr IOhannes
2017-03-03 18:36 GMT-03:00 Roman Haefeli reduzent@gmail.com:
Follow my instructions.
I did, quite carefully, didn't work as I said, I also did other stuff that I described, and didn't work as well.
On Fre, 2017-03-03 at 18:55 -0300, Alexandre Torres Porres wrote:
2017-03-03 18:36 GMT-03:00 Roman Haefeli reduzent@gmail.com:
Follow my instructions.
I did, quite carefully, didn't work as I said, I also did other stuff that I described, and didn't work as well.
Please be specific in what exactly didn't work. After putting deken- plugin.tcl into extra/, don't you see a message from Deken in the Pd- console when you start Pd? If not, then something is wrong already there.
Please try to be very specific also in what steps you performed, I mean if you're still interested in receiving help. Otherwise I must assume you downloaded deken-plugin.tcl by copy&pasting from browser to Microsoft Word and saved it as deken-plugin.tcl.
Roman
2017-03-03 19:20 GMT-03:00 Roman Haefeli reduzent@gmail.com:
After putting deken-plugin.tcl into extra/, don't you see a message from Deken in the Pd-console when you start Pd?
no, I don't
I must assume you downloaded deken-plugin.tcl by copy&pasting from browser to Microsoft Word and saved it as deken-plugin.tcl.
nope, I downloaded as it is.
So, if I just put in "extra", I get no message, no change in behaviour, and, like I said, my pd has a pd_deken.tcl file in a tcl folder outside the extra folder, that's the one that needs to be replaced, so it seems...
So, I just repeated myself, so what does it mean? I'm trying to say that this file that is there still counts... how do I know? If I delete it, I get a tcl error saying the file couldn't be found... even if I have that other one in the extra folder, like you suggested.
Now, if I replace the tcl file I have for the new renamed downloaded file, like I also said, nothing new happens, it doesn't offer me to install in the non existing ~Library/Pd folder.
that's all I really have to say :/
cheers
On Fre, 2017-03-03 at 19:55 -0300, Alexandre Torres Porres wrote:
2017-03-03 19:20 GMT-03:00 Roman Haefeli reduzent@gmail.com:
After putting deken-plugin.tcl into extra/, don't you see a message from Deken in the Pd-console when you start Pd?
no, I don't
I must assume you downloaded deken-plugin.tcl by copy&pasting from browser to Microsoft Word and saved it as deken-plugin.tcl.
nope, I downloaded as it is.
So, if I just put in "extra", I get no message, no change in behaviour, and, like I said, my pd has a pd_deken.tcl file in a tcl folder outside the extra folder, that's the one that needs to be replaced, so it seems...
So, I just repeated myself, so what does it mean? I'm trying to say that this file that is there still counts... how do I know? If I delete it, I get a tcl error saying the file couldn't be found... even if I have that other one in the extra folder, like you suggested.
Now, if I replace the tcl file I have for the new renamed downloaded file, like I also said, nothing new happens, it doesn't offer me to install in the non existing ~Library/Pd folder.
that's all I really have to say :/
OK. In the meanwhile, I had the chance to make my own test on a Mac (10.6, though) and I think I figured out what was going on. IOhannes gave the critical clue: Overriding only happens with a _newer_ version.
I think this happened:
You downloaded the new deken-plugin.tcl and saved it at Pd.app/.../tcl/pd_deken.tcl. By doing this you upgraded the internal deken script. Then I advised you to put deken-plugin.tcl into Pd.app/.../extra. However, no message from Deken appeared in the Pd console, because it did _not_ override the internal, because both internal and the one in extra had the same version. Thus, we thought you were not able to the test the new version, but you actually tested it, we just didn't notice.
But why did it not create the folder /Users/alex/Library/Pd, you may ask now? You said, you have admin rights on your Mac and you can write into XX.app folders without elevated privileges. I assume you have the checkbox "allow to manage this computer" (translated from German) checked for your user in system preferences. So, when you download the Pd.app and put it to /Applications, you're still the owner of that folder and you keep write permissions. Deken looks through search paths and finds one that is writable, thus it does not suggest to install to /Users/alex/Library/Pd. I logged in to the same computer with a different user (without "manage this computer" privileges) and - tadah: Deken asks and creates the user specific folder. So the feature indeed does work, also on Macs.
Can we close this thread with 'works as designed'?
Roman
Is there on linux an environment variable for this ?
Because on my archlinux system application specific data are located at a different place in ~/.local/share
Le 01/03/2017 à 21:17, IOhannes m zmölnig a écrit :
to answer you question more specifically: because ~/.local/lib/ is the standard (as defined by freedesktop specs) place on linux systems to put application specific data.
On 03/01/2017 09:57 PM, patrice colet wrote:
Is there on linux an environment variable for this ?
Because on my archlinux system application specific data are located at a different place in ~/.local/share
nah. there are slightly different semantics between ~/.local/share and ~/.local/lib.
~/.local/lib: Static, private vendor data ~/.local/share: Resources shared between multiple packages, such as fonts or artwork.
afaik, only ~/.local/share can be specified via an envvar XDG_DATA_HOME.
this is all specified in [1]
fdamdsr IOhannes
[1] https://www.freedesktop.org/software/systemd/man/file-hierarchy.html#Home%20...
-
Alexandre Torres Porres -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Lucas Cordiviola -
patrice colet -
Roman Haefeli -
zmoelnig＠iem.at