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 <[email protected]> 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 > > > > > > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list > >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
