I mean completely hide, no trace at all. The way it is now is intimidating.
The correct fix IMHO would be to make pd support ~/.local/share/pd-externals on GNU/Linux, then make all platforms install into there by default. .hc IOhannes m zmoelnig: > 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. > >> >> * 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. > > >> >> * 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/listinfo/pd-list