Re: [PD] deken install user experience

[Miller Puckette]

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 :
> 
> > 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


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] deken install user experience

[Alexandre Torres Porres]

btw, roughly when could we see a 0.47-1 update?

cheers

2016-06-14 21:32 GMT-03:00 Miller Puckette :

> 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

Re: [PD] deken install user experience

[Miller Puckette]

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

Re: [PD] deken install user experience

[Lucas Cordiviola]

I'm not insisting, but problematic/conflicting externals once detected can be 
excluded from the “All” package.
But it's just an idea.


Mensaje telepatico asistido por maquinas.

> To: pd-list@lists.iem.at
> From: colet.patr...@free.fr
> Date: Thu, 9 Jun 2016 20:58:08 +0200
> Subject: Re: [PD] deken install user experience
> 
> 
> 
> Le 09/06/2016 à 20:16, Lucas Cordiviola a écrit :
> >
> > One simple solution will be to have one zip containing all externals 
> > (updated monthly?) this will be the most simple and interesting for 
> > new users.
> 
> I don't know in this case how to avoid conflicts, sometimes I have to 
> remove mrpeach from path for having other externals to work, don't ask 
> me why because I don't know.
> 
> ___
> 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

Re: [PD] deken install user experience

[patrice colet]

Le 09/06/2016 à 20:16, Lucas Cordiviola a écrit :


One simple solution will be to have one zip containing all externals 
(updated monthly?) this will be the most simple and interesting for 
new users.


I don't know in this case how to avoid conflicts, sometimes I have to 
remove mrpeach from path for having other externals to work, don't ask 
me why because I don't know.


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] deken install user experience

[Lucas Cordiviola]

  > 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.


One simple solution will be to have one zip containing all externals (updated 
monthly?) this will be the most simple and interesting for new users.
This will bring back the benefits of “extended”.
By benefits I mean that as a student you are exposed to the work of all 
externals devs, it`s there, you open the browser and open zexy, cyclone, ggee, 
etc. 
With Vanilla you don't even know that there is a library of externals called 
mpreach.



Mensaje telepatico asistido por maquinas.   
  ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] deken install user experience

[Lucas Cordiviola]

> 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.
Totally,
I distribute my patches with all needed externals included, for all platforms, 
this way the user ONLY have to install pd and its ready to listen. He/she just 
open the patch and it works, no need to deken or -path or whatever, it just 
work.
I think its Ok that other platforms zips are grayed out.


Mensaje telepatico asistido por maquinas.

  ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] deken install user experience

[Dan Wilcox]

Before the discussion on deken installing libraries for you goes super far, we 
talked about this curing Chris’ initial deken development and, regarding, 
auto-magically downloading dependencies:

1. Pd developer time is currently limited (Chris & IOhannes were basically 
spitballing at that point), so the focus instead was put more on getting the 
basics working, especially in binary lib upload, search, & install.

2. Auto-magic dependency was put into the “nice to have, but possibly a lot of 
work to get right” pile as opposed to “must have" pile. If it turns out to be 
trivial, then by all means someone can propose some code and we can try it out 
(deken has it’s own GitHub repo after all).

3. There is no easy way around the pd-extended kitchen sink -> pd vanilla 
barebones + libs transition, [declare] is the preferred way forward in that 
regard. At least I thought that was agreed upon...

IMO the much bigger issue right now is that we don’t have full coverage of 
built external deken packages for all the main extended libraries for all 
platforms yet. If we (I am!) are worried about priority with limited resources, 
I feel this is much more important right now. We need a big push of people 
essentially updating these main libs to the pd-lib-builder makefile and then 
coordinating people on various platforms to build said libs and upload deken 
packages. The makefile can do that as a makefile target, so it’s relatively 
easy. After all, how can deken suggest a lib to install when there aren’t that 
many libs in deken to being with?

One of the great things about deken is that it helps decentralize the kitchen 
sink. Now, we need everyone to grab a utensil and start scrubbing :)


Dan Wilcox
@danomatika <https://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
> On Jun 9, 2016, at 4:00 AM, pd-list-requ...@lists.iem.at wrote:
> 
> From: Max <abonneme...@revolwear.com <mailto:abonneme...@revolwear.com>>
> Subject: Re: [PD] deken install user experience
> Date: June 9, 2016 at 3:00:27 AM MDT
> To: Roman Haefeli <reduz...@gmail.com <mailto:reduz...@gmail.com>>, 
> pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>
> 
> 
> 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.

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] deken install user experience

[Dan Wilcox]

I agree with Hans.

My 2 cents: I kind of like ~/pd-externals and use it for both deken and my own 
git clones of various abstraction libs, etc. I don;t mind it being “in the way” 
as I routinely work from it on my own libs.

IMO there should be a deken path setting in the Path dialog with 
~/.local/lib/pd/extra as default. Then I could go in, change the path to 
~/pd-externals and it uses that from then on, until I change it.

I don’t think deken should do any sort of auto-trickery at all, but have a 
plain default location you can change that doesn’t require choosing a directory 
each time you install something. Another option could be to create a deken 
settings dialog which could be launched from a button in the deken GUI proper. 
This way, we’d get a settings location without having to add anything directly 
to the pdsettings. There could be a similar .dekensettings file along side that 
simply stores the download path for now, which could be expanded if we need 
other info. I’d be willing to mock that up if needed.

In any case, I’m glad to see people weighing in on deken and helping to improve 
it. Sorry all of this feedback didn’t come earlier, before the 0.47 release and 
when you had to manually install it, but such is life.


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 
> On Jun 9, 2016, at 2:33 AM, pd-list-requ...@lists.iem.at wrote:
> 
> 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.

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] deken install user experience

[Chris McCormick]

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.

--
http://mccormick.cx/

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] deken install user experience

[Roman Haefeli]

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

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] deken install user experience

[IOhannes m zmoelnig]

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



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] deken install user experience

[IOhannes m zmoelnig]

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



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] deken install user experience

[IOhannes m zmoelnig]

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





signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] deken install user experience

[Max]

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


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] deken install user experience

[Max]

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.

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] deken install user experience

[cyrille henry]

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

Re: [PD] deken install user experience

[Roman Haefeli]

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

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] deken install user experience

[Roman Haefeli]

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

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] deken install user experience

[IOhannes m zmoelnig]

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).

fgmsadr
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] deken install user experience

[IOhannes m zmölnig]

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)



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] deken install user experience

[Hans-Christoph Steiner]

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
> 
> 
> 
> [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

Re: [PD] deken install user experience

[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



[1] https://github.com/pure-data/deken








signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] deken install user experience

[Hans-Christoph Steiner]

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