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@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@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list