[PD] deken install user experience

[Hans-Christoph Steiner]

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
> 
> 
> 
> 
> 
>