On Wed, 2016-06-08 at 14:00 +0200, IOhannes m zmoelnig wrote:
On 2016-06-08 12:09, Hans-Christoph Steiner wrote:
I'd like to find a little time to contribute to it, to smooth out the user
cool. welcome back.
- hide all incompatible library version by default (e.g. hide OSX
and Windows versions on GNU/Linux)
this is what we are currently doing. all incompatible versions are sorted after the compatible ones, and (more importantly) they are greyed out. they are still selectable though.
Sorry if I missed this, but what is the point of displaying incompatible (wrong arch, wrong platform) Deken packages? What would be harmed if they'd be hidden completely? I fail to see the advantage of having the possibility of downloading a package of wrong arch/platform.
- by default, install into user's pd externals folder without any
prompt (~/pd-externals, etc)
hmm, well: there has been a lot of discussion on this list about which approach should be taken.
a short (probably biased) recap (but you'll find more detailed reasoning in the archives):
- originally, deken would try to download/install into the externals
folder (as your suggestion). it would even try to create this folder, in case it was not there yet. this was rejected, as many people very much dislike applications creating folders in their home directory (~/pd-externals).
- a second iteration did the same, but without trying to create any
directories. if no writable folder was found, deken would prompt the user for a target directory) this was rejected because people have very different opinions about the scope of downloaded externals (per-user, per-project, per-pd).
- a third iteration added a big button to manually set the directory
before downloading stuff (and otherwise would try the standard search paths first). this was rejected because it was not obvious. (which only shows that i'm a bad UI designer)
- the fourth iteration went for simplicity and prompted the user
where to install.
currently, Pd-vanilla uses the 4th iteration, wheras deken upstream still uses the 3rd iteration.
And current behavior (4th iteration) is still unlucky. Retrospectively, my conclusion is it is a flawed approach to have a discussion with mostly expert users and try to respect their different workflows. The result seems to disregard the needs of newcomers and users that don't want to get bothered with anything that is not a "standard" workflow. First of all, the tool should just _do_ what is sensible, since the user doesn't necessarily know what is sensible. Prompting for a download directory can already be confusing. To tell from my own experience, on one box the directory ~/.local/lib/pd/extra already existed and Deken sensibly proposed to install libraries there. On another box there was no ~/.local/lib/pd/extra and Deken proposed my home directory as install dir! What are inexperienced people supposed to do with that?! There is no point ever in install libraries directly to my home. Every other behavior I can imagine is better than proposing my home directory as library install path. Of course, even inexperienced users don't want to install their externals in their home so they just make something up, like ~/pd/extra. However, ~/pd/extra is not a default search path and whatever they try to run (for instance, they downloaded netpd and netpd [declare]s all necessary libraries) and it will fail, because [delcare]d stuff needs to be in any of the standard search paths. The users spend quite some time investigating the issue of not loaded libraries, and since they are not aware of the magic of default search paths (how should they know, when they do not read the pd mailing list and Deken doesn't even give a hint of a sensible install path?) they will figure out you can specify search paths in the Pd preferences. So they go through the trouble of adding all libraries in the non-default location ~/pd/extra/ and they finally can successfully run the patch. However, they achieved it by adapting their preferences to the patch they want to run! That's so much not what we want people think they have to do, changing their preferences for whatever project they run!
In my ideal world, I write a Pd project, make sure it properly declares what it needs and then people who want to run my project find a list in the documentation with the required externals (with no further explanation how to do that and where to install). After installing the externals from the list, my pd project runs on their box and is able to successfully load the libraries. We're not there yet, see above.
Even for experienced users who want to support their special workflow, the prompt for a directory doesn't make sense in my opinion. I think someone mentioned that they have several local installs of Pure Data on their box and they host different sets of libraries for each Pd installation. Even in this case, the prompt is annoying. I rather would edit the deken-plugin.cnf of each included deken-plugin and override the default search path (~/.local/lib/pd/extra) with '<my-local-pd-for- experimenting>/extra/'. What I'm trying to say is that experienced users know already about search paths and they're probably much more comfortable with editing a cnf file than having to deal with a GUI file browser each time they download something. So I'm not seeing whom the browser prompt actually is supposed to help.
Another thing, that I feel was a crucial part in the reason for having so many iterations, is that people complained about Pd creating a directory in the user's home without asking (~/pd-externals). While I understand that concern, the reason to address this just vanished with the switch to ~/.local/lib/pd/extra. pd-externals was annoying, but I doubt anybody would ever complain about Pd creating ~/.local/lib/pd/extra, so ___pplleeaazzee__ let's Deken do its thing and create this directory. It'll avoid so much unnecessary pain.
Long story short, I'm pretty much with Hans in this regard. Let's Deken automatically download to a sensible directory.
Just to chime in about unzipping-in-Windows aspect, from what I can tell that would smoothen the Deken experience for Windows users _a lot_.
Thanks to all the Deken contributors.
Roman
- add "Advanced Mode" or "Expert Mode" that shows the current user
experience
- remember which mode the user has selected across pd starts (e.g.
make a pref)
yes, many more things should be user-settable, not just two basic modes. e.g. directory-selection: - [ ] ask every time - [x] ask once per Pd process - [ ] choose automatically from existing search-paths - [ ] choose automatically, possibly creating default locations
as for search results, i was thinking about switching to a tree-view, where only the most recent version of a found library would be shown by default; but opening the (sub)tree, you would see all the older versions. the wrong-arch results could be grouped together into an "incompatible" subtree that is closed by default.
in any case: deken development is somewhat independent of puredata itself and is occasionally merged into Pd proper. it has it's own bug/feature tracker at [1] and we are happily accepting merge requests and contributors.
fgmasdr IOhannes
[1] https://github.com/pure-data/deken
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/lis tinfo/pd-list