New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Request: initially suggest "standard user specific" folder for download #156
Comments
Oh, so, there is this recent Pull Request from @danomatika to Pd here: pure-data/pure-data#140 - which may relate to this suggestion a bit. The thing is that the entry path from that pull request loads the path which is set in deken. But initially that's empty, and only after downloading from deken something shows up there. So, it seems that if you initially suggest the user specific folder for download, then that would be there out of the box, instead of an empty field. |
@porres sounds good to me. |
This should be fixed in #155 |
If I get this correctly, you mean that it doesn't show an empty filed out of the box anymore, right? But we'd still need a Pull Request to initially suggest user specific folder for download, right? |
Yes.
No. When you use deken it asks as it did before which is the (one discussed) preferred default. |
Not sure what you mean, I don't think the "extra" was ever discussed and agreed as the preferred location, and that's not how deken works. I guess you probably know all this and I'm likely being repetitive, but anyway... deken actually has a priority to download to the user specific folder already, and it'll first prompt you to download it the when first launching Pd, but only if you already have that folder. The second option in this order would be the global folder, and the last is the application specific folder - by the way, this order comes from Pd, not deken, and I think it makes sense. What deken does is that if you cannot download it anywhere (that is if you don't have user/global folders or writing privileges for the "extra" folder), it prompts you to download to the user folder. So maybe we could agree now which is the preferred default.
Awesome, and how do you think it'd be best to approach a solution? I see now that when I'm suggesting not to download at first to "extra", this would imply in a change that would prevent deken to first propose that one. But if the user wants to download things there, he can just browse there, and deken will remember it between restarts. We now have this another way to set the download path, thanks to Dan, which makes all this much, much easier. cheers |
It's the first "safe" place which is guaranteed to exist and, since it is installed/comes with Pd, is most likely writable, hence it is the default if no deken path has been saved. If you look at the code, it 's basically the first system path that Pd uses.
Yes.
This is why the first system path is used as a reasonable default: it's guaranteed to be there.
It's different on many platforms so it's more than reasonable to say "here's the default, change if you like." A long part of the discussion on the list, if I remember, was that many people did not like the idea of being forced to use a specific folder or even a "standard" folder. You can argue that all over again but, please, I suggest writing much shorter (& fewer) emails. It's sometimes so much that I honestly don't read very much... |
Well, which discussion do you mean? Discussions can tenfold into related topics and it may seem this was argued before, but this proposal (user specific folder instead of extra) is being first brought up here, so there's no argument to be re edited. However, I've been referring to the "Deken Install User Experience" thread on the pd list - which I wasn't involved, so don't blame me if it was long for reading or if it reached nowhere :) This thread mentions a previous discussion on automatically creating folders, and the end of it was a proposal to allow the creation back, see: https://lists.puredata.info/pipermail/pd-list/2016-06/115377.html - where I quote @umlaeute "it seems indeed that the main obstacle for automatic directory creation has gone with this new default user-specific search path. if there is some consensus, i will happily re-enable the directory creation. (but it seems that everybody has gone into sleep mode again, and will only awake after the next release)" By the way, the next release would be now ;) Yes, I did at one point or another try to revive that discussion on the pd list, to see if it would reach a final conclusion, and it didn't. Yes, if the folder was automatically created, I wouldn't have an issue to point it out here. But note that I'm not reviving any discussion here, I'm not arguing that we should automatically create folders. I'm bringing up a different idea/solution. cheers |
Ok, let me put it another way: "I have no more time for this. I am not going to do anything more on this for now." I am already chasing bugs on multiple platforms as it is (and wondering why I'm bothering right now...). |
yeah, that's what I'm saying, that we should prompt for the "user standard path" as a default, and people can change that if they like. |
How does it not do that already? I really don't understand you now. As far as I know, the behavior from my Path dialog update PR for a fresh/empty install is:
With the Path dialog, the behavior is:
Are you suggesting a dialog pops up the first time Pd is started? That's pretty annoying, especially to people that might want to keep stuff in the default location as the popup may keep showing up every time they run Pd. I tested adding a popup when you open the Path dialog & the install path is empty, but it's also annoying. Anyway, the real fix is for deken to choose a default location and/or create that location per platform, not for popups. I am not going to do that right now. |
All I'm suggesting is which is the default. Note I said: "we should prompt for the "user standard path" as a default, and people can change that if they like." This is all that there is to the issue I opened here, a request to "initially suggest user specific folder for download" Right now it prompts for extra as default, if you have writing privileges to it and you don't have a "user standard path". And I did argue in my first comment here how I think that is bad. In short, it's the "application specific path" so things get lost when upgrading, probably only advanced users would wanna use it. Moreover, this is not the folder that gets picked for windows (cause it ain't writable), so it makes things inconsistent in cross platforms. Windows people get prompted for the "user specific folder" already, and that folder is created if it doesn't exist. Mac users usually get "extra". I hoped it'd also get the "user specific folder" cause it'd be consistent and a better choice. I'm repeating myself again, so I'll stop! Hope it is clear now, I can add more details and repeat myself if necessary. The request in short: Initially prompt for "standard user specific path" as a default first time around, cause it's better thanks for giving attention to this |
Yes, that's what I propose/request, that it chooses the "standard user specific path" location by default!
It already creates it after the user hits "yes"! |
Sorry if I got you wrong, but do you mean "extra" is the first default folder for deken? Cause it's not. In Macs, It prompts for "user specific standard path" first (~/Library/Pd on Mac), but that is if you have it. |
this is the situation for the latest pd-0.48.test6 on Windows: if the user specific folder exist, deken will suggest it, otherwise it will suggest extra. this is bad, as Alex has explained. OR deken always suggests the user specific path first and if you try to download there it will create it for you if it doesn't exist. don't know what is better? generally, I don't see any argument against creating the user specific folder automatically as this is what all programs do which have a folder there. it's absurd to assume that the user should create it. this can only be a workaround. |
A solution already in progress is that deken can already create the "user specific folder" (aka user specific "standard path") if it is not there, but it has to suggest it first. But it doesn't suggest when it finds the extra folder as a writable one. Hence, my solution is that it initially suggests the "user specific folder". It's that simple!
I wouldn't know, but you can always say "no, I don't want that one" and choose another, so it would still work as you say - that is, people who downloaded the zip and want the extra folder, may still do so. Again, a simple, elegant, and power solution |
+1! I think you haven't seen my edit yet :-). |
Wait, I was saying thought in windows it didn't suggest "extra" as it wasn't writable, so instead it'd suggest the "user standard folder" and create it. But now I see it actually prompts you for extra, so it's also bad for windows!!! Maybe something weird is happening to Pd0.48, as it asks to downlaod to Pd48/bin/bin/bin/bin/extra (4 "bin"s? seriously?). Well, bottom line is that I thought things were at least ok for windows, but now I see it's also bad for it! |
well, this has been sorted with a new mechanism and many additions from @danomatika to Pd 0.48-0 (which is out, so I'm closing this) |
Howdy, if I understand it correctly, deken searches for "standard paths" and prompts you for the first one it finds. If it can't find a valid one, it suggests the creation of the "standard user specific" folder. This seems to be working since this commit: 8625a44
This is extremely important for windows, as there was no valid download path deken could find and now this is solved! I understand there was a concern on automatically adding "standard folders", but this solution did meet halfway, and allowed the creation of such folder at request.
But unfortunately this still doesn't quite happen for MacOS, cause it'll easily find the /extra folder if you got admin powers (which is what you have by default, if the machine is yours), so it'll just prompt you to download there.
This situation isn't ideal, as I believe the extra folder should not be the best option to install externals. This standard path is the "application specific" folder, and means that it gets lost when you upgrade to a new Pd and throw the old one away. Only advanced users who know what they're doing, and have multiple/different versions of Pd, may want to use it, not all users, who are mostly not savyy enough.
So my suggestion here is to simply suggest in all operating system to first download to the "standard user specific" folder at request. And if the user agrees, it'll create it for them. The biggest change was already done. What I'm proposing simply makes it consistent between cross platforms.
cheers
The text was updated successfully, but these errors were encountered: