thought we'd finally change the thread name... for those who are getting there now, this is the discussion about a new deken feature, that would suggest to download to the system user folder and then create it if it's not there. I was testing the new version and it didn't work.
2017-03-04 6:30 GMT-03:00 Roman Haefeli reduzent@gmail.com:
But why did it not create the folder /Users/alex/Library/Pd (...)?
It actually didn't suggest to write to ~/Library/Pd, which needed to happen first, the creation of the folder would be the next step.
you have admin rights on your Mac and you can write into XX.app folders (...) Deken looks through search paths and finds one that is writable, thus it does not suggest to install to /Users/alex/Library/Pd.
Can we close this thread with 'works as designed'?
I thought the design was to suggest to write into the ~/Library/Pd folder, and then create it. This is not what's happening! It only suggests it if it didn't find any folder it can use. In the end, there is no difference for me.
So, for it to suggest to download to ~/Library/Pd, I have to first create that folder myself, and the whole discussion here seemed to be the need to create that folder automatically, to make things easier for the user.
cheers
2017-03-04 13:00 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
the whole discussion here seemed to be the need to create that folder automatically, to make things easier for the user.
I dont know if it's clear what a complex user experience it is to manage externals in Pd right now. Seems that the whole idea with deken and all was to make it painless, but we're not there yet.
Why creating such folders (like the user folder) would be better for the user? Cause now it's just hard because you need to create the folder yourself, and that requires, first of all, prior knowledge on how pd works internally, which might be fine for developers, but not to users... second, the ~/Library isn't normally viewable in the finder on a Mac, so you also gotta have knowledge that it this folder is hidden, where it is hidden, and how to hack the system so you can see it...
Yes, this is for the Mac, but other systems have other peculiarities, which just unfolds and adds complexity. But they do have a similar logic/idea, that the user doesn't or shouldn't have to touch some folders, since they can be dummies who may screw up and compromise the system. Therefore, is it the *Software* that creates folders in such a place... but not Pd... and the decision to not do it was consciously made, but I still don't know why.
I have asked a few times now, I still have no answer to why there's a good reasoning not to do it when Pd is installed on your machine... I looked for previous discussion in the list, I couldn't find, any possibility anybody would join in and answer me please?
Anyway, since Pd does not create it, for some reason, we're down to giving that task to the deken plugin, but it's not quite there yet. Nonetheless, I still think the best solution is that Pd installs the system folders automatically when it is installed (not only the user-specific in *~/Library*, but also the global in */Library*).
Other features that would make things easier for the user is that if both deken and the "Preferences => Path" tab had easy access to the folders Pd automatically searches for externals (global, user and application). As it is, it's simply impossible to navigate to the user-specific folder and also to the application folder. On the other hand, I can actually navigate to the system folder (/Library) just fine in Mac Os.
So, as it is, the most convenient place for mac users to install externals is the global folder, so they can easily navigate there in the Path... or in the Finder to manually drop or delete folders. That is, if only it had been created there...
I hope I have made it clear how complicated and still somewhat painful managing externals in Pd still is, and how there's much room por improvement! It was only when I sat down and wrote a 13 page tutorial on how to manage externals that I realized how hard it is, cause I didn't even addressed all of these issues.
cheers
Oh, please allow to reason that even if the new deken feature, as it'll also remember the last choice and keeps it, it won't ever propose/create that user folder again.
That's actually an issue even if it proposes to download to the user folder, no matter what, at first, because if you do not choose it the first time, it'll never propose it again.
if we're gonna stick to the idea of no making pd create the folders, but deken, I think it'd be nice if there was a menu of regular folder paths it can install to, and then query the user to create the folder if it doesn't exist. Such folders would be the application, user and global, for each system, of course. If you wanna download somewhere else, a 4th option could be "other", which opens the savemenu dialog.
cheers
2017-03-04 13:09 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
2017-03-04 13:00 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
the whole discussion here seemed to be the need to create that folder automatically, to make things easier for the user.
I dont know if it's clear what a complex user experience it is to manage externals in Pd right now. Seems that the whole idea with deken and all was to make it painless, but we're not there yet.
Why creating such folders (like the user folder) would be better for the user? Cause now it's just hard because you need to create the folder yourself, and that requires, first of all, prior knowledge on how pd works internally, which might be fine for developers, but not to users... second, the ~/Library isn't normally viewable in the finder on a Mac, so you also gotta have knowledge that it this folder is hidden, where it is hidden, and how to hack the system so you can see it...
Yes, this is for the Mac, but other systems have other peculiarities, which just unfolds and adds complexity. But they do have a similar logic/idea, that the user doesn't or shouldn't have to touch some folders, since they can be dummies who may screw up and compromise the system. Therefore, is it the *Software* that creates folders in such a place... but not Pd... and the decision to not do it was consciously made, but I still don't know why.
I have asked a few times now, I still have no answer to why there's a good reasoning not to do it when Pd is installed on your machine... I looked for previous discussion in the list, I couldn't find, any possibility anybody would join in and answer me please?
Anyway, since Pd does not create it, for some reason, we're down to giving that task to the deken plugin, but it's not quite there yet. Nonetheless, I still think the best solution is that Pd installs the system folders automatically when it is installed (not only the user-specific in *~/Library*, but also the global in */Library*).
Other features that would make things easier for the user is that if both deken and the "Preferences => Path" tab had easy access to the folders Pd automatically searches for externals (global, user and application). As it is, it's simply impossible to navigate to the user-specific folder and also to the application folder. On the other hand, I can actually navigate to the system folder (/Library) just fine in Mac Os.
So, as it is, the most convenient place for mac users to install externals is the global folder, so they can easily navigate there in the Path... or in the Finder to manually drop or delete folders. That is, if only it had been created there...
I hope I have made it clear how complicated and still somewhat painful managing externals in Pd still is, and how there's much room por improvement! It was only when I sat down and wrote a 13 page tutorial on how to manage externals that I realized how hard it is, cause I didn't even addressed all of these issues.
cheers
2017-03-04 13:32 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
Such folders would be the application, user and global, for each system, of course. If you wanna download somewhere else, a 4th option could be "other", which opens the savemenu dialog.
the same idea could be applied to the "Path" in preferences, and this has already been brought up by me in another thread. Dan gave a *+1* on it (for the path) and also suggested this:
2017-02-18 3:03 GMT-02:00 Dan Wilcox danomatika@gmail.com:
Maybe a good example would be the Processing preferences dialog: http://robotosha.ru/wp-content/uploads/2014/09/ preferences_window_processing.png
thought i'd connect these dots to better organize the discussion.
anyway, easily navigating though the path to reach app/user/global folders would also require them to be created before hand, somehow. So the creation of such folders is the key element here.
cheers
On Sam, 2017-03-04 at 13:09 -0300, Alexandre Torres Porres wrote:
2017-03-04 13:00 GMT-03:00 Alexandre Torres Porres porres@gmail.com :
the whole discussion here seemed to be the need to create that folder automatically, to make things easier for the user.
I dont know if it's clear what a complex user experience it is to manage externals in Pd right now. Seems that the whole idea with deken and all was to make it painless, but we're not there yet.
I was troubled by the fact the Pd user was expected to have prior knowledge of sane paths before they could successfully use Deken. That's why I am a proponent of the creating the user specific folder (assuming that this would be only user writable one, which is not necessarily true, we see now). Now, things are pretty good, you can use Deken and rely on it that it will find a good location for you. Of course, if you want to be "smart" you can screw things up, but this true with any software system. So I really can't share your notion that things are complex from a user perspective. You can use Deken out of the box now. You actually don't need to know all the complexities behind the scenes for it to work. But I do think it is good for me and for you that you went through the trouble of documenting all this. It's good that _we_ know how things work.
Why creating such folders (like the user folder) would be better for the user? Cause now it's just hard because you need to create the folder yourself, and that requires, first of all, prior knowledge on how pd works internally, which might be fine for developers, but not to users... second, the ~/Library isn't normally viewable in the finder on a Mac, so you also gotta have knowledge that it this folder is hidden, where it is hidden, and how to hack the system so you can see it...
Yes, this is for the Mac, but other systems have other peculiarities, which just unfolds and adds complexity.
On Windows >= 7 and on any Linux I know the only user writable option is the user specific folder. I know now this is not true on Macs, depending on what check boxes you checked in the system preferences for the user. Does it harm? Deken still silently works, you can download externals and then - more importantly - load them in Pd without thinking about paths at any time.
But they do have a similar logic/idea, that the user doesn't or shouldn't have to touch some folders, since they can be dummies who may screw up and compromise the system. Therefore, is it the Software that creates folders in such a place... but not Pd... and the decision to not do it was consciously made, but I still don't know why.
I have asked a few times now, I still have no answer to why there's a good reasoning not to do it when Pd is installed on your machine... I looked for previous discussion in the list, I couldn't find, any possibility anybody would join in and answer me please?
As far as I know, most software doesn't write any user specific stuff at installation time. How should it know which users are going to use the software and what happens if a user is added _after_ installation? It totally makes sense to create any directories and/or write files when they are actually needed. Pd doesn't need /Users/alex/Library/Pd, so why should it create it?
Anyway, since Pd does not create it, for some reason, we're down to giving that task to the deken plugin, but it's not quite there yet. Nonetheless, I still think the best solution is that Pd installs the system folders automatically when it is installed (not only the user- specific in ~/Library, but also the global in /Library).
Other features that would make things easier for the user is that if both deken and the "Preferences => Path" tab had easy access to the folders Pd automatically searches for externals (global, user and application). As it is, it's simply impossible to navigate to the user-specific folder and also to the application folder.
On the other hand, I can actually navigate to the system folder (/Library) just fine in Mac Os.
So, as it is, the most convenient place for mac users to install externals is the global folder, so they can easily navigate there in the Path... or in the Finder to manually drop or delete folders. That is, if only it had been created there...
I hope I have made it clear how complicated and still somewhat painful managing externals in Pd still is, and how there's much room por improvement! It was only when I sat down and wrote a 13 page tutorial on how to manage externals that I realized how hard it is, cause I didn't even addressed all of these issues.
It's hard if you want to do specific stuff that requires special knowledge. I don't see how it is hard if you want to just download and use an external. Having said that, loading stuff from libraries correctly is still complex, more complex than necessary, in my opinion. I wish calling the library by name would be enough, regardless of its internal layout.
Roman
2017-03-04 15:54 GMT-03:00 Roman Haefeli reduzent@gmail.com:
I really can't share your notion that things are complex from a user perspective. You can use Deken out of the box now.
Yes, with the new feature you can, and you couldn't before! My point is not that it won't work, but that it can still be further improved beyond the advancement being made right now.
On Windows >= 7 and on any Linux I know the only user writable option is the user specific folder. I know now this is not true on Macs depending on what check boxes you checked in the system preferences for
the user.
It works out of the box for macs, you don't need to set anything up, that's my experience... but I guess you can alter the system and prevent it.
So, our thing is that Pd has all these folders as "Standard Paths" but not all are usable or writeable. Actually, besides the application folder, they're not even created by the software. So we need to find a common ground and it seems to be the user folder. So that's a good option for a default setting that's consistent for all operating systems. Good.
As far as I know, most software doesn't write any user specific stuff at installation time. How should it know which users are going to use the software and what happens if a user is added _after_ installation?
If a user is installing the software, then it can deduce that this user is going to use the software. In the same ~/Library folder here on my mac is where the */Audio* folder is, including the *MIDI Drivers* and *Plug-ins*. All plugins installers write in here and install the plugins you can use in Ableton Live, for instance. And Ableton Live has no problem in searching for the plugins over there. That's an example...
It totally makes sense to create any directories and/or write files
when they are actually needed. Pd doesn't need /Users/alex/Library/Pd so why should it create it?
How come it doesn't need it? Isn't it one of Pd's Standasr Paths for starters?More over, isn't the folder we're realizing is the only writeable and best option for all platforms? What do you mean? Sorry, I don't get it.
It's hard if you want to do specific stuff that requires special knowledge.
All that is hard can be made easier... I just suggested a few solutions.
I don't see how it is hard if you want to just download and use an external.
There are different options for downloading and using an external. Right now, this is not well documented or made easy to achieve. Ok, we got one step further with this update and at least we can download and use it.
Having said that, loading stuff from libraries correctly is still complex,
more complex than necessary, in my opinion.
great, then we're on the same track after all.
I wish calling the library by name would be enough, regardless of its internal layout.
+1 on that
cheers
Oh, and it's not like Pd doesn't already write stuff in "~/Library", it actually does create files in "~/Library/preferences", so it's not like it's a sacred ground it can't touch... I'm still yet to understand what is the issue of Pd creating a folder in here...
Though I can agree it is a rather unusual place to go. Most softwares won't do it, and the reason this is being discussed is just that Pd happens to have that folder as a standard path in the first place... so it's coming from Pd for some reason. Now, I can see most softwares prefer to use other folders in the user area, outside this hidden ~/Library folder. For instance, audiosculpt went for ~/Applications. Max and Native Instruments went for ~/Documents. The place to install externals for Max is in ~/Documents/Max/Packages.
There's also the "shared" folder. I see Max and Native Instruments there too. So if you want to install something for all users, that folder seems to be the one to go.
So I'm now leaning on actually disregarding ~/Library as a good choice for creating and using as an external destination... not sure yet why there's a resistance it's a bad place to go... but if this is why, well, maybe a better option like these other folders would do.
That would actually work and solve thew other problems I was raising, where you can't navigate to the ~/Library folder if you want to add it in your "Path".
This is all for Mac OS of course, and we should check the options for other systems.
cheers
2017-03-04 19:59 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
2017-03-04 15:54 GMT-03:00 Roman Haefeli reduzent@gmail.com:
I really can't share your notion that things are complex from a user perspective. You can use Deken out of the box now.
Yes, with the new feature you can, and you couldn't before! My point is not that it won't work, but that it can still be further improved beyond the advancement being made right now.
On Windows >= 7 and on any Linux I know the only user writable option is the user specific folder. I know now this is not true on Macs depending on what check boxes you checked in the system preferences for
the user.
It works out of the box for macs, you don't need to set anything up, that's my experience... but I guess you can alter the system and prevent it.
So, our thing is that Pd has all these folders as "Standard Paths" but not all are usable or writeable. Actually, besides the application folder, they're not even created by the software. So we need to find a common ground and it seems to be the user folder. So that's a good option for a default setting that's consistent for all operating systems. Good.
As far as I know, most software doesn't write any user specific stuff at installation time. How should it know which users are going to use the software and what happens if a user is added _after_ installation?
If a user is installing the software, then it can deduce that this user is going to use the software. In the same ~/Library folder here on my mac is where the */Audio* folder is, including the *MIDI Drivers* and *Plug-ins*. All plugins installers write in here and install the plugins you can use in Ableton Live, for instance. And Ableton Live has no problem in searching for the plugins over there. That's an example...
It totally makes sense to create any directories and/or write files
when they are actually needed. Pd doesn't need /Users/alex/Library/Pd so why should it create it?
How come it doesn't need it? Isn't it one of Pd's Standasr Paths for starters?More over, isn't the folder we're realizing is the only writeable and best option for all platforms? What do you mean? Sorry, I don't get it.
It's hard if you want to do specific stuff that requires special knowledge.
All that is hard can be made easier... I just suggested a few solutions.
I don't see how it is hard if you want to just download and use an external.
There are different options for downloading and using an external. Right now, this is not well documented or made easy to achieve. Ok, we got one step further with this update and at least we can download and use it.
Having said that, loading stuff from libraries correctly is still complex,
more complex than necessary, in my opinion.
great, then we're on the same track after all.
I wish calling the library by name would be enough, regardless of its internal layout.
+1 on that
cheers
So I'm now leaning on actually disregarding ~/Library as a good choice
for creating and using as an external destination...
+1 on this...
i just had a classroom of students navigate to ~/Library and create ~/Library/Pd .... its quite a pain to teach some of these basic skills. for some reason this particular class had security concerns with create such a folder (maybe because last assessment we got into a lengthy anonymity/snowden/darkweb/hacking discussion)....
anyway was this not all discussed and decided upon in pdx dev days?
i am not sure about deken new functions but unless its in millers core it doesn't matter seeing thats where i have students download from.
BTW arduino and processing also both install libraries in:
~/Documents
and as porres might say "just saying"
m
On Sat, Mar 4, 2017 at 6:24 PM, Alexandre Torres Porres porres@gmail.com wrote:
Oh, and it's not like Pd doesn't already write stuff in "~/Library", it actually does create files in "~/Library/preferences", so it's not like it's a sacred ground it can't touch... I'm still yet to understand what is the issue of Pd creating a folder in here...
Though I can agree it is a rather unusual place to go. Most softwares won't do it, and the reason this is being discussed is just that Pd happens to have that folder as a standard path in the first place... so it's coming from Pd for some reason. Now, I can see most softwares prefer to use other folders in the user area, outside this hidden ~/Library folder. For instance, audiosculpt went for ~/Applications. Max and Native Instruments went for ~/Documents. The place to install externals for Max is in ~/Documents/Max/Packages.
There's also the "shared" folder. I see Max and Native Instruments there too. So if you want to install something for all users, that folder seems to be the one to go.
So I'm now leaning on actually disregarding ~/Library as a good choice for creating and using as an external destination... not sure yet why there's a resistance it's a bad place to go... but if this is why, well, maybe a better option like these other folders would do.
That would actually work and solve thew other problems I was raising, where you can't navigate to the ~/Library folder if you want to add it in your "Path".
This is all for Mac OS of course, and we should check the options for other systems.
cheers
2017-03-04 19:59 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
2017-03-04 15:54 GMT-03:00 Roman Haefeli reduzent@gmail.com:
I really can't share your notion that things are complex from a user perspective. You can use Deken out of the box now.
Yes, with the new feature you can, and you couldn't before! My point is not that it won't work, but that it can still be further improved beyond the advancement being made right now.
On Windows >= 7 and on any Linux I know the only user writable option is the user specific folder. I know now this is not true on Macs depending on what check boxes you checked in the system preferences for
the user.
It works out of the box for macs, you don't need to set anything up, that's my experience... but I guess you can alter the system and prevent it.
So, our thing is that Pd has all these folders as "Standard Paths" but not all are usable or writeable. Actually, besides the application folder, they're not even created by the software. So we need to find a common ground and it seems to be the user folder. So that's a good option for a default setting that's consistent for all operating systems. Good.
As far as I know, most software doesn't write any user specific stuff at installation time. How should it know which users are going to use the software and what happens if a user is added _after_ installation?
If a user is installing the software, then it can deduce that this user is going to use the software. In the same ~/Library folder here on my mac is where the */Audio* folder is, including the *MIDI Drivers* and *Plug-ins*. All plugins installers write in here and install the plugins you can use in Ableton Live, for instance. And Ableton Live has no problem in searching for the plugins over there. That's an example...
It totally makes sense to create any directories and/or write files
when they are actually needed. Pd doesn't need /Users/alex/Library/Pd so why should it create it?
How come it doesn't need it? Isn't it one of Pd's Standasr Paths for starters?More over, isn't the folder we're realizing is the only writeable and best option for all platforms? What do you mean? Sorry, I don't get it.
It's hard if you want to do specific stuff that requires special knowledge.
All that is hard can be made easier... I just suggested a few solutions.
I don't see how it is hard if you want to just download and use an external.
There are different options for downloading and using an external. Right now, this is not well documented or made easy to achieve. Ok, we got one step further with this update and at least we can download and use it.
Having said that, loading stuff from libraries correctly is still
complex, more complex than necessary, in my opinion.
great, then we're on the same track after all.
I wish calling the library by name would be enough, regardless of its internal layout.
+1 on that
cheers
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
2017-03-06 18:22 GMT-03:00 Dan Wilcox danomatika@gmail.com:
I agree that something in the ~/Documents would be more standard than anything in ~/Library as that has been a hidden folder in Finder since OS X 10.7 or so as is not meant to be directly user-accessible. The preferences file, OTOH, should stay as that uses the same format & location that most macOS apps use.
sure, but that resides in *~/Library/Preferences*, not *~/Library/Pd -* so we can just forget about *~/Library/Pd* with no effect.
So, I'm making a list of things that would improve the experience.
windows too?) like it was done for linux.
Have the Pd install create those folders for you.
Deken can then suggest the user folder in the first time ever that it
runs (which is not doing even with the new feature). User can change it and it'll remember the choice between restarts (this feature has been implemented already).
First things first, but there'd be more to think about.
Installing in the application specific folder is tricky, and not much can be done as it's something to do with the system allowing write privileges. The option is to make a better documentation about it. I could do that, and I've already started an extensive "howto manage externals" tutorial.
This has also been discussed, but with better standard folders, some issues with adding the path to Pd's preferences is automatically solved, as you could now easily navigate there. But dealing with the application specific folder is still a pain in Mac Os - I just had to guide someone on the facebook group to manage that.
2017-02-18 3:03 GMT-02:00 Dan Wilcox danomatika@gmail.com:
Maybe a good example would be the Processing preferences dialog: http://robotosha.ru/wp-content/uploads/2014/09/prefe rences_window_processing.png
I have to say I never got the main idea of this example, but it should be easy to have an option to automatically navigate to the application's extra folder somehow.
Will all this, I think installing externals from deken or not would be an actual painless experience.
cheers
2017-03-18 16:27 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
2017-03-06 18:22 GMT-03:00 Dan Wilcox danomatika@gmail.com:
I agree that something in the ~/Documents would be more standard than anything in ~/Library as that has been a hidden folder in Finder since OS X 10.7 or so as is not meant to be directly user-accessible. The preferences file, OTOH, should stay as that uses the same format & location that most macOS apps use.
sure, but that resides in *~/Library/Preferences*, not *~/Library/Pd -* so we can just forget about *~/Library/Pd* with no effect.
On Mar 18, 2017, at 1:49 PM, Alexandre Torres Porres porres@gmail.com wrote:
2017-02-18 3:03 GMT-02:00 Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com>: Maybe a good example would be the Processing preferences dialog: http://robotosha.ru/wp-content/uploads/2014/09/preferences_window_processing... http://robotosha.ru/wp-content/uploads/2014/09/preferences_window_processing.png
I have to say I never got the main idea of this example, but it should be easy to have an option to automatically navigate to the application's extra folder somehow.
The idea is that the Processing preferences does two things regarding it’s sketchbook & library path:
My point was it would be a good idea if Pd also let’s you do the same regarding deken’s install path.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On 03/18/2017 11:07 PM, Dan Wilcox wrote:
- shows you where it currently is (after having created the default ~/Documents/Processing folder on first run if it doesn’t exist)
- allows you to change the path
My point was it would be a good idea if Pd also let’s you do the same regarding deken’s install path.
which of these things does deken *not* do right now?
gfmar IOhannes
2017-03-18 19:34 GMT-03:00 IOhannes m zmölnig zmoelnig@iem.at:
On 03/18/2017 11:07 PM, Dan Wilcox wrote:
- shows you where it currently is (after having created the default
~/Documents/Processing folder on first run if it doesn’t exist)
- allows you to change the path
My point was it would be a good idea if Pd also let’s you do the same
regarding deken’s install path.
which of these things does deken *not* do right now?
So, Dan says Processing creates the default ~/Documents/Processing folder on first run if it doesn’t exist.
I thought we were doing the same with the new deken, but as I said in the first message on this thread: "*I thought the design was to suggest to write into the ~/Library/Pd folder, and then create it. This is not what's happening! It only suggests it if it didn't find any folder it can use. In the end, there is no difference for me*"
I had no difference, because deken offered to write in the application specific folder, and since it remembers that folder, it will never to suggest the ~/Library/Pd or create it...
Anyway, my suggestion was that Pd (or deken, whatever) could create the system standard folders, as softwares usually do. I get that back in the day, people had issues with pd creating a folder in linux home, but that seems to have been taken care of, and changed. I still don't get if there's a resistance in automatically creating these folders currently.
A parallel discussion in this thread is that the system folders change in MacOS, since ~/Library/Pd is an unusual and inconvenient place for that (an example is processing using ~/Documents instead)
cheers
On 2017-04-06 06:20, Alexandre Torres Porres wrote:
A parallel discussion in this thread is that the system folders change in MacOS, since ~/Library/Pd is an unusual and inconvenient place for that (an example is processing using ~/Documents instead)
i think ~/Documents is for user-created documents, whereas ~/Libraries is for storing resources related to an application, such as plugins and libraries [1]. afaict, a Pd-library (e.g. downloaded via deken) very much belongs into the category of "plugins and libraries", rather than "user-created documents". so according to Apple's guidelines, ~/Library/Pd seems to be the correct place to install Pd-libraries into.
iiuic, ~/Documents/Pd would be used for storing the patches you are currently working on. this probably should be the default working directory on OSX (i unfondly remember the days when it used to be '/')
i think the processing analogy also only takes the being-worked-on documents into account, rather than reusable libraries.
(as i sidenote, this makes it out of the scope for deken (so nothing that *i* would implement ;-)))
fgmsdrt IOhannes
[1] https://developer.apple.com/library/content/documentation/FileManagement/Con...
i think ~/Documents is for user-created documents,
The Processing and Arduino folders in ~/Documents contain a 'libraries' subfolder, which is considered the default place for user-installed libraries. But in the end, that's just the Processing way.
BTW, one thing I don't find so elegant (maybe that has changed now...) is that Deken will ask you *if* it should install the library in the default folder and you have to click 'no' to choose another directory. the question itself is a bit ambiguous and it doesn't seem very intuitive. IMHO it should rather ask you *where* to install by opening the panel. Just my two cents.
Gesendet: Donnerstag, 06. April 2017 um 17:22 Uhr Von: "IOhannes m zmoelnig" zmoelnig@iem.at An: pd-list@lists.iem.at Betreff: Re: [PD] New deken feature, create system user folder
On 2017-04-06 06:20, Alexandre Torres Porres wrote:
A parallel discussion in this thread is that the system folders change in MacOS, since ~/Library/Pd is an unusual and inconvenient place for that (an example is processing using ~/Documents instead)
i think ~/Documents is for user-created documents, whereas ~/Libraries is for storing resources related to an application, such as plugins and libraries [1]. afaict, a Pd-library (e.g. downloaded via deken) very much belongs into the category of "plugins and libraries", rather than "user-created documents". so according to Apple's guidelines, ~/Library/Pd seems to be the correct place to install Pd-libraries into.
iiuic, ~/Documents/Pd would be used for storing the patches you are currently working on. this probably should be the default working directory on OSX (i unfondly remember the days when it used to be '/')
i think the processing analogy also only takes the being-worked-on documents into account, rather than reusable libraries.
(as i sidenote, this makes it out of the scope for deken (so nothing that *i* would implement ;-)))
fgmsdrt IOhannes
[1] https://developer.apple.com/library/content/documentation/FileManagement/Con...
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
yeah this might be apple "conceptual" method but it seems in practice applications (lately?) are preferring to use ~/Documents as the catchall for libs,user created docs, examples, etc.
so processing, for example, in ~/Documents has folders:
examples libraries modes templates tools
similar for arduino although default install online has ~/Documents/Arduino/libraries
now that I am looking I even have an "Adobe" folder here where it looks like is stored all presets, user preferences, logs etc. AND in they un-typically install plugins/libs in /Applcations/Adobe */Plugins
there are prob many other examples of softwares throwing lib folders all over OSX
processing/arduino also make folders in ~/Libraries but they seem to be only preferences...
cheers m
On Thu, Apr 6, 2017 at 11:22 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2017-04-06 06:20, Alexandre Torres Porres wrote:
A parallel discussion in this thread is that the system folders change in MacOS, since ~/Library/Pd is an unusual and inconvenient place for that
(an
example is processing using ~/Documents instead)
i think ~/Documents is for user-created documents, whereas ~/Libraries is for storing resources related to an application, such as plugins and libraries [1]. afaict, a Pd-library (e.g. downloaded via deken) very much belongs into the category of "plugins and libraries", rather than "user-created documents". so according to Apple's guidelines, ~/Library/Pd seems to be the correct place to install Pd-libraries into.
iiuic, ~/Documents/Pd would be used for storing the patches you are currently working on. this probably should be the default working directory on OSX (i unfondly remember the days when it used to be '/')
i think the processing analogy also only takes the being-worked-on documents into account, rather than reusable libraries.
(as i sidenote, this makes it out of the scope for deken (so nothing that *i* would implement ;-)))
fgmsdrt IOhannes
[1] https://developer.apple.com/library/content/documentation/ FileManagement/Conceptual/FileSystemProgrammingGuide/MacOSXDirectories/ MacOSXDirectories.html
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
I can add, again, the example that Max uses ~/Documents for installing plug-in externals and stuff.
just saying...
Yeah, some softwares will use ~/Library, but not like we're using, that is a "Pd" folder in ~/Library, but choose ~/Library/Application Support/SoftwareName instead.
Moreover, softwares that do that and install plug-ins there have a better plug-in install manager that makes things easy for the user, and actually do not make the user go there to do that stuff. We don't have such a user friendly manager like that with deken (far from it), so an easy (or, better put, "*easier*" alternative) would be to use a more accessible and friendlier target, like Max, Arduino, Processing do.
I could go for either way, but thought it was simpler and easier to set a new target folder.
cheers
2017-04-06 14:13 GMT-03:00 me.grimm megrimm@gmail.com:
yeah this might be apple "conceptual" method but it seems in practice applications (lately?) are preferring to use ~/Documents as the catchall for libs,user created docs, examples, etc.
so processing, for example, in ~/Documents has folders:
examples libraries modes templates tools
similar for arduino although default install online has ~/Documents/Arduino/libraries
now that I am looking I even have an "Adobe" folder here where it looks like is stored all presets, user preferences, logs etc. AND in they un-typically install plugins/libs in /Applcations/Adobe */Plugins
there are prob many other examples of softwares throwing lib folders all over OSX
processing/arduino also make folders in ~/Libraries but they seem to be only preferences...
cheers m
On Thu, Apr 6, 2017 at 11:22 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2017-04-06 06:20, Alexandre Torres Porres wrote:
A parallel discussion in this thread is that the system folders change
in
MacOS, since ~/Library/Pd is an unusual and inconvenient place for that
(an
example is processing using ~/Documents instead)
i think ~/Documents is for user-created documents, whereas ~/Libraries is for storing resources related to an application, such as plugins and libraries [1]. afaict, a Pd-library (e.g. downloaded via deken) very much belongs into the category of "plugins and libraries", rather than "user-created documents". so according to Apple's guidelines, ~/Library/Pd seems to be the correct place to install Pd-libraries into.
iiuic, ~/Documents/Pd would be used for storing the patches you are currently working on. this probably should be the default working directory on OSX (i unfondly remember the days when it used to be '/')
i think the processing analogy also only takes the being-worked-on documents into account, rather than reusable libraries.
(as i sidenote, this makes it out of the scope for deken (so nothing that *i* would implement ;-)))
fgmsdrt IOhannes
[1] https://developer.apple.com/library/content/documentation/Fi leManagement/Conceptual/FileSystemProgrammingGuide/MacOSXDir ectories/MacOSXDirectories.html
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/li stinfo/pd-list
-- ____________________ m.e.grimm, m.f.a, ed.m. syracuse u., tc3 megrimm.net ____________________
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
2017-04-06 15:36 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
We don't have such a user friendly manager like that with deken (far from it)
been saying it before, but in any case, by that, I mean:
previous knowledge) 2) you can't navigate to that folder in Pd Vanilla to add it to your preferences path (and Pd only add paths that you can navigate to). So you need to create an alias for that invisible folder to your desktop, then use it to find the path
this is all for mac os, of course
ways around that would be to auto create the folder and change it to a visible and findable path (like ~/Documents) or redesign pd's interface (which I feel is unlikelier to expect). But a visible folder in Documents will always be simpler, cause it's not always the case that you will download libraries from the library manager (deken). So now that I thought more about it, even if you redesign Pd's interface, this will still be an issue for mac users.
cheers
- the folder is not created for you, you have to pre create it
(requiring previous knowledge
if deken isn't going to automate this on osx maybe just simple copy and paste in a terminal (or?) for new users:
$ mkdir ~/Library/Pd && mkdir ~/Documents/Pd && ln -s ~/Library/Pd ~/Documents/Pd/libraries
at least in a workshop/class setting maybe
might be easier than finder -> go -> go to settings -> ~/Libraries and making Pd directory THEN creating alias to wherever
m
On Thu, Apr 6, 2017 at 3:06 PM, Alexandre Torres Porres porres@gmail.com wrote:
2017-04-06 15:36 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
We don't have such a user friendly manager like that with deken (far from it)
been saying it before, but in any case, by that, I mean:
- the folder is not created for you, you have to pre create it (requiring
previous knowledge) 2) you can't navigate to that folder in Pd Vanilla to add it to your preferences path (and Pd only add paths that you can navigate to). So you need to create an alias for that invisible folder to your desktop, then use it to find the path
this is all for mac os, of course
ways around that would be to auto create the folder and change it to a visible and findable path (like ~/Documents) or redesign pd's interface (which I feel is unlikelier to expect). But a visible folder in Documents will always be simpler, cause it's not always the case that you will download libraries from the library manager (deken). So now that I thought more about it, even if you redesign Pd's interface, this will still be an issue for mac users.
cheers
Aliases are needed one way or another, cause you can only browse to a folder, when you're adding a path to Pd's preferences...
This is not an issue in windows (not sure about linux...)
and I think is easier to hit a shortcut that goes to ~/Library ;) (command
cheers
2017-04-07 18:01 GMT-03:00 me.grimm megrimm@gmail.com:
- the folder is not created for you, you have to pre create it
(requiring previous knowledge
if deken isn't going to automate this on osx maybe just simple copy and paste in a terminal (or?) for new users:
$ mkdir ~/Library/Pd && mkdir ~/Documents/Pd && ln -s ~/Library/Pd ~/Documents/Pd/libraries
at least in a workshop/class setting maybe
might be easier than finder -> go -> go to settings -> ~/Libraries and making Pd directory THEN creating alias to wherever
m
On Thu, Apr 6, 2017 at 3:06 PM, Alexandre Torres Porres porres@gmail.com wrote:
2017-04-06 15:36 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
We don't have such a user friendly manager like that with deken (far from it)
been saying it before, but in any case, by that, I mean:
- the folder is not created for you, you have to pre create it
(requiring previous knowledge) 2) you can't navigate to that folder in Pd Vanilla to add it to your preferences path (and Pd only add paths that you can navigate to). So you need to create an alias for that invisible folder to your desktop, then use it to find the path
this is all for mac os, of course
ways around that would be to auto create the folder and change it to a visible and findable path (like ~/Documents) or redesign pd's interface (which I feel is unlikelier to expect). But a visible folder in Documents will always be simpler, cause it's not always the case that you will download libraries from the library manager (deken). So now that I thought more about it, even if you redesign Pd's interface, this will still be an issue for mac users.
cheers