[PD] deken install user experience

[Matt Barber]

Users on the Facebook group have complained that on Windows they have to
take the extra step of unzipping. Is there a way to include a simple
windows binary with Pd that would decompress automatically?

On Wed, Jun 8, 2016 at 8:00 AM, IOhannes m zmoelnig <zmoelnig at iem.at> 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.
>
> >
> > * 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 at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160608/a28cf31c/attachment-0001.html>