Re: [PD] deken install user experience

[Roman Haefeli]

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

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

[Max]

on reddit are some interesting helpless deken experiences too:
https://www.reddit.com/r/puredata/comments/4hdtcg/making_pd_pure_like_pdextended/




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
> 


___
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/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




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



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

[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

[Roman Haefeli]

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




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

[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 mailto:abonneme...@revolwear.com>>
> Subject: Re: [PD] deken install user experience
> Date: June 9, 2016 at 3:00:27 AM MDT
> To: Roman Haefeli 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

[patrice colet]

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.



___
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

[Roman Haefeli]

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
ins

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 zmoelnig]

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



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



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

[patrice colet]

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


___
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

[Dan Wilcox]

Chris went over this many different ways and the main issue is that Pd 
currently still relies largely on Tk 8.4. Tcl/Tk 8.5 comes with built in unzip 
support, which is one reason why I’m trying to get Pd working on OSX without 
needing 8.4 anymore. IMHO Pd should be on TK 8.5 on all platforms, if not 8.6 
at this point.

We also looked into using batch scripts to call the native Windows unzip but 
there wasn’t any way to do that without requiring a 3rd party tool like 7zip. 
Maybe that’s changed now, but one issue is always that Pd needs to support old 
OSes to some degree.

If any of those Windows people on the Facebook group would know how to 
accomplish this, let us know...


Dan Wilcox
@danomatika <https://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
> On Jun 8, 2016, at 10:24 AM, pd-list-requ...@lists.iem.at wrote:
> 
> From: Matt Barber mailto:brbrof...@gmail.com>>
> Subject: Re: [PD] deken install user experience
> Date: June 8, 2016 at 10:24:10 AM MDT
> To: Pd List mailto:pd-l...@iem.at>>
> 
> 
> 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?

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

Re: [PD] deken install user experience

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

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