I'm just trying deken for the first time, awesome piece of work! I'd like to find a little time to contribute to it, to smooth out the user experience for newbies. I can see there are all sorts of use cases for all of the install options that it currently provides, but it is pretty confusing for most people who just want to use a library. I don't want to step on any toes, so I thought I'd throw out some ideas here:
- hide all incompatible library version by default (e.g. hide OSX and
Windows versions on GNU/Linux)
- by default, install into user's pd externals folder without any prompt
(~/pd-externals, etc)
- 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)
.hc
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
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
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
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
On 06/08/2016 06:56 PM, Hans-Christoph Steiner wrote:
I mean completely hide, no trace at all. The way it is now is intimidating.
please create a ticket on github. i still believe that a collapsed subtree view would be ok.
The correct fix IMHO would be to make pd support
that's unrelated to "no trace at all", isn't it?¹
~/.local/share/pd-externals on GNU/Linux,
which Pd-0.47-1 (not yet released) already supports (6406700c)
then make all platforms install into there by default.
i'm not sure i understand that sentence.
apart from that, this has really been discussed at length. please read it up in the archives.
msdr IOhannes
¹ since there are different multiple issues addressed in this mail thread, would you mind giving context in your replies? (e.g. replying inline rather than TOFU)
hello,
I tried to follow deken discussions and would like to jump on topic for pointing out two missing methods...
one is about adding a lib and/or a path entry in PureData preferences, and the other is about removing/disabling deken installed external files and pref...
best,
pc
Le 08/06/2016 à 20:07, IOhannes m zmölnig a écrit :
On 06/08/2016 06:56 PM, Hans-Christoph Steiner wrote:
I mean completely hide, no trace at all. The way it is now is intimidating.
please create a ticket on github. i still believe that a collapsed subtree view would be ok.
The correct fix IMHO would be to make pd support
that's unrelated to "no trace at all", isn't it?¹
~/.local/share/pd-externals on GNU/Linux,
which Pd-0.47-1 (not yet released) already supports (6406700c)
then make all platforms install into there by default.
i'm not sure i understand that sentence.
apart from that, this has really been discussed at length. please read it up in the archives.
msdr IOhannes
¹ since there are different multiple issues addressed in this mail thread, would you mind giving context in your replies? (e.g. replying inline rather than TOFU)
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 2016-06-09 08:19, patrice colet wrote:
one is about adding a lib and/or a path entry in PureData preferences
afaict there is agreement that dependencies should be [declare]d in the patch, rather than system-wide. this makes the ability to automatically add libs/paths to the preferences a very low priority.
fgmasdr IOhannes
On Thu, 2016-06-09 at 10:01 +0200, IOhannes m zmoelnig wrote:
On 2016-06-09 08:19, patrice colet wrote:
one is about adding a lib and/or a path entry in PureData preferences
afaict there is agreement that dependencies should be [declare]d in the patch, rather than system-wide. this makes the ability to automatically add libs/paths to the preferences a very low priority.
+1
Roman
Le 09/06/2016 à 10:01, IOhannes m zmoelnig a écrit :
On 2016-06-09 08:19, patrice colet wrote:
one is about adding a lib and/or a path entry in PureData preferences
afaict there is agreement that dependencies should be [declare]d in the patch, rather than system-wide. this makes the ability to automatically add libs/paths to the preferences a very low priority.
Having deken proposing solutions for resolving missing patch dependencies looks very interesting, it should save a lot of time to users that want to collaborate on same patches from different machines.
In the same way it would be nice if deken could resolve external's libraries dependencies (eg:readanysf~ on windows needs a dozen of dlls to work) by downloading them in the right place or at least proposing install methods from a "README.md like" file or using the meta file from the external that would popup or appear on console when objects couldn't create.
On 2016-06-09 08:19, patrice colet wrote:
and the other is about removing/disabling deken installed external
ys that would be nice to have. however, it is non-trivial with the current "package architecture" (which is just a zip-file that gets unpacked) to track which files got installed by a given package.
what i think is fairly important is to at least track which packages are already installed (without having to keep the archive-files around and without cluttering some easily visible directory)
fgmsdrt IOhannes
On Thu, 2016-06-09 at 10:06 +0200, IOhannes m zmoelnig wrote:
On 2016-06-08 20:07, IOhannes m zmölnig wrote:
i still believe that a collapsed subtree view would be ok.
but that's not to say that i would be opposed to totally hiding incompatible packages (as long as you can easily unhide them).
I'm not opposed to either way, but why do you insist on the ability to unhide them?
Roman
On Wed, 2016-06-08 at 14:00 +0200, IOhannes m zmoelnig 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.
Sorry if I missed this, but what is the point of displaying incompatible (wrong arch, wrong platform) Deken packages? What would be harmed if they'd be hidden completely? I fail to see the advantage of having the possibility of downloading a package of wrong arch/platform.
- 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.
And current behavior (4th iteration) is still unlucky. Retrospectively, my conclusion is it is a flawed approach to have a discussion with mostly expert users and try to respect their different workflows. The result seems to disregard the needs of newcomers and users that don't want to get bothered with anything that is not a "standard" workflow. First of all, the tool should just _do_ what is sensible, since the user doesn't necessarily know what is sensible. Prompting for a download directory can already be confusing. To tell from my own experience, on one box the directory ~/.local/lib/pd/extra already existed and Deken sensibly proposed to install libraries there. On another box there was no ~/.local/lib/pd/extra and Deken proposed my home directory as install dir! What are inexperienced people supposed to do with that?! There is no point ever in install libraries directly to my home. Every other behavior I can imagine is better than proposing my home directory as library install path. Of course, even inexperienced users don't want to install their externals in their home so they just make something up, like ~/pd/extra. However, ~/pd/extra is not a default search path and whatever they try to run (for instance, they downloaded netpd and netpd [declare]s all necessary libraries) and it will fail, because [delcare]d stuff needs to be in any of the standard search paths. The users spend quite some time investigating the issue of not loaded libraries, and since they are not aware of the magic of default search paths (how should they know, when they do not read the pd mailing list and Deken doesn't even give a hint of a sensible install path?) they will figure out you can specify search paths in the Pd preferences. So they go through the trouble of adding all libraries in the non-default location ~/pd/extra/ and they finally can successfully run the patch. However, they achieved it by adapting their preferences to the patch they want to run! That's so much not what we want people think they have to do, changing their preferences for whatever project they run!
In my ideal world, I write a Pd project, make sure it properly declares what it needs and then people who want to run my project find a list in the documentation with the required externals (with no further explanation how to do that and where to install). After installing the externals from the list, my pd project runs on their box and is able to successfully load the libraries. We're not there yet, see above.
Even for experienced users who want to support their special workflow, the prompt for a directory doesn't make sense in my opinion. I think someone mentioned that they have several local installs of Pure Data on their box and they host different sets of libraries for each Pd installation. Even in this case, the prompt is annoying. I rather would edit the deken-plugin.cnf of each included deken-plugin and override the default search path (~/.local/lib/pd/extra) with '<my-local-pd-for- experimenting>/extra/'. What I'm trying to say is that experienced users know already about search paths and they're probably much more comfortable with editing a cnf file than having to deal with a GUI file browser each time they download something. So I'm not seeing whom the browser prompt actually is supposed to help.
Another thing, that I feel was a crucial part in the reason for having so many iterations, is that people complained about Pd creating a directory in the user's home without asking (~/pd-externals). While I understand that concern, the reason to address this just vanished with the switch to ~/.local/lib/pd/extra. pd-externals was annoying, but I doubt anybody would ever complain about Pd creating ~/.local/lib/pd/extra, so ___pplleeaazzee__ let's Deken do its thing and create this directory. It'll avoid so much unnecessary pain.
Long story short, I'm pretty much with Hans in this regard. Let's Deken automatically download to a sensible directory.
Just to chime in about unzipping-in-Windows aspect, from what I can tell that would smoothen the Deken experience for Windows users _a lot_.
Thanks to all the Deken contributors.
Roman
- 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/lis tinfo/pd-list
Le 09/06/2016 10:33, Roman Haefeli a écrit :
In my ideal world, I write a Pd project, make sure it properly declares what it needs and then people who want to run my project find a list in the documentation with the required externals
in an other ideal world, [declare] notice that the declared lib is not installed, so it ask if deken should install it...
cheers c
ok, cyrille was 2 minutes faster with the idea. Chapeau.
On 2016년 06월 09일 17:58, cyrille henry wrote:
Le 09/06/2016 10:33, Roman Haefeli a écrit :
In my ideal world, I write a Pd project, make sure it properly declares what it needs and then people who want to run my project find a list in the documentation with the required externals
in an other ideal world, [declare] notice that the declared lib is not installed, so it ask if deken should install it...
cheers c
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 2016-06-09 10:58, cyrille henry wrote:
Le 09/06/2016 10:33, Roman Haefeli a écrit :
In my ideal world, I write a Pd project, make sure it properly declares what it needs and then people who want to run my project find a list in the documentation with the required externals
in an other ideal world, [declare] notice that the declared lib is not installed, so it ask if deken should install it...
so because cyrille was faster than max, i'm answering this: i think it should be fairly simple to implement that functionality as a "loader".
since Pd-0.47, loaders can differentiate whether they should search for a library in a given directory, or "wherever they please" (this is a last ressort, after all the search-paths have been walked). and this would be the perfect time to fire up deken, and prefill it with the search term (so the user only needs to hit "search").
the drawbacks are, that the loader cannot really distinguish whether Pd tried to load a library ("zexy") or an objectclass ("demultiplex"), and deken is really only good at finding libraries.
it also might get triggered multiple times (e.g. because my patch is full of unavailable [nop]s)
therefore i don't think it would be a good idea to
- make this used by default (for nuisance reasons)
- automatically start the search (for privacy reasons)
mnfgasdr IOhannes
On 2016년 06월 09일 17:33, Roman Haefeli wrote:
In my ideal world, I write a Pd project, make sure it properly declares what it needs and then people who want to run my project find a list in the documentation with the required externals (with no further explanation how to do that and where to install). After installing the externals from the list, my pd project runs on their box and is able to successfully load the libraries. We're not there yet, see above.
Or even better: the receipient opens the file, Pd realizes that it depends on not installed libraries, prompts "should Pd install the missing libraries x, y and z?" then she/he clicks yes or abort.
On 2016-06-09 10:33, Roman Haefeli wrote:
Sorry if I missed this, but what is the point of displaying incompatible (wrong arch, wrong platform) Deken packages? What would be harmed if they'd be hidden completely? I fail to see the advantage of having the possibility of downloading a package of wrong arch/platform.
like: preparing your patch for offline use on multiple archs, which you currently don't have access to.
or: checking whether the library exists at all, and if I could nag its osx maintainer to give me w32 binaries.
fgmsdr IOhannes
On Thu, 2016-06-09 at 14:14 +0200, IOhannes m zmoelnig wrote:
On 2016-06-09 10:33, Roman Haefeli wrote:
Sorry if I missed this, but what is the point of displaying incompatible (wrong arch, wrong platform) Deken packages? What would be harmed if they'd be hidden completely? I fail to see the advantage of having the possibility of downloading a package of wrong arch/platform.
like: preparing your patch for offline use on multiple archs, which you currently don't have access to.
or: checking whether the library exists at all, and if I could nag its osx maintainer to give me w32 binaries.
Right. Both makes sense to me.
Roman
On 2016-06-09 10:33, Roman Haefeli wrote:
Just to chime in about unzipping-in-Windows aspect, from what I can tell that would smoothen the Deken experience for Windows users _a lot_.
well, test it https://github.com/pure-data/deken/tree/w32-unzip
amd if it works, chances are high that the it will soon be available for public consumation.
fgamsdr IOhannes
It's working for me. I've taken teh liberty of adding an "OK/cancel" confirnation that prints where the thing will get installed. (This is default behavior of apt-get, etc. so it's not too nutty of me to think this is a reasonable step. It's much less invasive than throwing the file chooser up as I was doing before but still makes sure the user can see where the thing's getting thrown to. (I think this is important since it apparently varies depending on several factors that can change between runs.)
Anyway the new unzipping thing works like a charm, thanks!
M
On Thu, Jun 09, 2016 at 02:17:01PM +0200, IOhannes m zmoelnig wrote:
On 2016-06-09 10:33, Roman Haefeli wrote:
Just to chime in about unzipping-in-Windows aspect, from what I can tell that would smoothen the Deken experience for Windows users _a lot_.
well, test it https://github.com/pure-data/deken/tree/w32-unzip
amd if it works, chances are high that the it will soon be available for public consumation.
fgamsdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
btw, roughly when could we see a 0.47-1 update?
cheers
2016-06-14 21:32 GMT-03:00 Miller Puckette msp@ucsd.edu:
It's working for me. I've taken teh liberty of adding an "OK/cancel" confirnation that prints where the thing will get installed. (This is default behavior of apt-get, etc. so it's not too nutty of me to think this is a reasonable step. It's much less invasive than throwing the file chooser up as I was doing before but still makes sure the user can see where the thing's getting thrown to. (I think this is important since it apparently varies depending on several factors that can change between runs.)
Anyway the new unzipping thing works like a charm, thanks!
M
On Thu, Jun 09, 2016 at 02:17:01PM +0200, IOhannes m zmoelnig wrote:
On 2016-06-09 10:33, Roman Haefeli wrote:
Just to chime in about unzipping-in-Windows aspect, from what I can tell that would smoothen the Deken experience for Windows users _a lot_.
well, test it https://github.com/pure-data/deken/tree/w32-unzip
amd if it works, chances are high that the it will soon be available for public consumation.
fgamsdr IOhannes
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
I'm just trying to fix a bug or two... but who knows how long that might take.
cheers M
On Tue, Jun 14, 2016 at 09:42:19PM -0300, Alexandre Torres Porres wrote:
btw, roughly when could we see a 0.47-1 update?
cheers
2016-06-14 21:32 GMT-03:00 Miller Puckette msp@ucsd.edu:
It's working for me. I've taken teh liberty of adding an "OK/cancel" confirnation that prints where the thing will get installed. (This is default behavior of apt-get, etc. so it's not too nutty of me to think this is a reasonable step. It's much less invasive than throwing the file chooser up as I was doing before but still makes sure the user can see where the thing's getting thrown to. (I think this is important since it apparently varies depending on several factors that can change between runs.)
Anyway the new unzipping thing works like a charm, thanks!
M
On Thu, Jun 09, 2016 at 02:17:01PM +0200, IOhannes m zmoelnig wrote:
On 2016-06-09 10:33, Roman Haefeli wrote:
Just to chime in about unzipping-in-Windows aspect, from what I can tell that would smoothen the Deken experience for Windows users _a lot_.
well, test it https://github.com/pure-data/deken/tree/w32-unzip
amd if it works, chances are high that the it will soon be available for public consumation.
fgamsdr IOhannes
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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 06/15/2016 02:32 AM, Miller Puckette wrote:
It's working for me. I've taken teh liberty of adding an "OK/cancel" confirnation that prints where the thing will get installed.
nice idea. in the deken repository i've changed this slightly to a "Yes/No/Cancel" dialog:
- yes proceeds to install to the displayed directory
- no opens a directory chooser to select an alternative install target
- cancel aborts installation
this allows us to get rid of the "set install dir" button altogether.
mgfdsar IOhannes
On 09/06/16 16:33, Roman Haefeli wrote:
Sorry if I missed this, but what is the point of displaying incompatible (wrong arch, wrong platform) Deken packages? What would be harmed if they'd be hidden completely? I fail to see the advantage of having the possibility of downloading a package of wrong arch/platform.
Almost always true: the software is dumber than the person using it.
omgskynet,
Chris.
On Wed, 2016-06-08 at 12:09 +0200, Hans-Christoph Steiner wrote:
- by default, install into user's pd externals folder without any
prompt (~/pd-externals, etc)
I'm trying to resume...
I believe yet all have agreed to ~/.local/lib/pd/extra as the default install path (and most recent Deken uses it).
There was some concerns about creating directories without asking. Now, do those concerns still apply with above default install path? It seems pretty normal that applications do stuff there. Is anyone still against auto-creating?
Roman
On 06/13/2016 11:25 AM, Roman Haefeli wrote:
I believe yet all have agreed to ~/.local/lib/pd/extra as the default install path (and most recent Deken uses it).
more important: (upcoming) Pd-0.47-1 uses it
There was some concerns about creating directories without asking. Now, do those concerns still apply with above default install path? It seems pretty normal that applications do stuff there. Is anyone still against auto-creating?
it seems indeed that the main obstacle for automatic directory creation has gone with this new default user-specific search path. if there is some consensus, i will happily re-enable the directory creation. (but it seems that everybody has gone into sleep mode again, and will only awake after the next release)
gfmadsr IOhannes
On Thu, 2016-06-16 at 20:15 +0200, IOhannes m zmölnig wrote:
On 06/13/2016 11:25 AM, Roman Haefeli wrote:
I believe yet all have agreed to ~/.local/lib/pd/extra as the default install path (and most recent Deken uses it).
more important: (upcoming) Pd-0.47-1 uses it
There was some concerns about creating directories without asking. Now, do those concerns still apply with above default install path? It seems pretty normal that applications do stuff there. Is anyone still against auto-creating?
it seems indeed that the main obstacle for automatic directory creation has gone with this new default user-specific search path. if there is some consensus, i will happily re-enable the directory creation. (but it seems that everybody has gone into sleep mode again, and will only awake after the next release)
OK, time to wake up, release is out! ;-)
Seriously, current implementation doesn't give a hint for a good choice of install directory (it suggests ~/ if there is no ~/.local/lib/pd/extra) . Even if the user-specific search directory is not auto-created, at least the plugin should give a hint of what is a sensible choice.
Roman
on reddit are some interesting helpless deken experiences too: https://www.reddit.com/r/puredata/comments/4hdtcg/making_pd_pure_like_pdexte...
On 2016년 06월 08일 19:09, Hans-Christoph Steiner wrote:
I'm just trying deken for the first time, awesome piece of work! I'd like to find a little time to contribute to it, to smooth out the user experience for newbies. I can see there are all sorts of use cases for all of the install options that it currently provides, but it is pretty confusing for most people who just want to use a library. I don't want to step on any toes, so I thought I'd throw out some ideas here:
- hide all incompatible library version by default (e.g. hide OSX and
Windows versions on GNU/Linux)
- by default, install into user's pd externals folder without any prompt
(~/pd-externals, etc)
- 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)
.hc
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Alexandre Torres Porres -
Chris McCormick -
cyrille henry -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Matt Barber -
Max -
Miller Puckette -
patrice colet -
Roman Haefeli