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):
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).
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).
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)
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:
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