Re: [PD] deken install user experience

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]

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

Re: [PD] deken install user experience

> 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

Re: [PD] deken install user experience

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

Re: [PD] deken install user experience

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

Re: [PD] deken install user experience

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

Re: [PD] Pd-extended appearance to Pd vanilla 0.46-7

Excuse me, I think I misspoke. I work with deken without problems. I was talking about the interface work area. I want the same same colors for cords, messages, objects, etc. There's a way using Tcl/tk? Thanks IOhannes and Luca Óscar Santis escultor, pintor, músico ruidista

Re: [PD] deken install user experience

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

Re: [PD] deken install user experience

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?

Re: [PD] deken install user experience

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

Re: [PD] deken install user experience

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

Re: [PD] deken install user experience

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 >

Re: [PD] PdCon16 -- 5th International Puredata Convention @ NYU

Jaime, It sounds great. I'd love to take part of PdCon16 cheers from brazil, rbrz Em qui, 9 de jun de 2016 00:30, Ivica Bukvic escreveu: > Very cool! > > -- > Ivica Ico Bukvic, D.M.A. > Associate Professor > Computer Music > ICAT Senior Fellow > Director -- DISIS, L2Ork >

Re: [PD] deken install user experience

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

Re: [PD] deken install user experience

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

Re: [PD] deken install user experience

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

Re: [PD] deken install user experience

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

Re: [PD] deken install user experience

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.

Re: [PD] deken install user experience

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