I'm sure there is a way. A quick check shows me that there is are a couple of options for unzipping with Tcl:
http://wiki.tcl.tk/17433 https://core.tcl.tk/tcllib/doc/trunk/embedded/www/tcllib/files/modules/zip/d...
That should just be included in either the deken plugin, or the pd windows build.
.hc
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@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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list