[PD-dev] removing path and libs from Pd-extended preferences GUI

[Hans-Christoph Steiner]

I totally agree that the default prefs should not be loading libs
globally. I think it'll be an easier transition if we do it in parts.  I
was thinking that we should remove all the global lib loading in this
next Pd-extended release, but it seems like to much with all the new GUI
changes as well.

.hc

On Tue, 2011-09-20 at 11:58 -0700, Miller Puckette wrote:
> OK .... that assuages most of my doubts.  I hadn't realized Pd extended
> has separate preferences; this is excellent news (preferences carrying
> over between the 2 was a major headache for me at one point in the past :)
> 
> I'd still suggest that, if you wnt to not have "startup lib loading" in
> the GUI it should get cleaned out of the preferences too - but I suspect
> you've already thought of that.
> 
> cheers
> Miller
> 
> On Tue, Sep 20, 2011 at 02:37:32PM -0400, Hans-Christoph Steiner wrote:
> > 
> > Hey Miller,
> > 
> > If I follow what you are saying, that you can create preferences in the
> > Pd-vanilla preferences GUI that Pd-extended will then load, that is no
> > longer true.  Pd-extended has a different preferences file from
> > Pd-vanilla (~/.pdextended, ~/Library/Pd/org.puredata.pdextended.plist,
> > etc).
> > 
> > It is a bit confusing that Pd-extended is loading libraries globally at
> > startup, you can see those in the debug output in the Pd window.
> > Ultimately, I think Pd-extended should not load any libraries by
> > default.  That will be a big transition that will take more prep work,
> > so I think we should defer that to a later release.
> > 
> > .hc
> > 
> > On Tue, 2011-09-20 at 11:16 -0700, Miller Puckette wrote:
> > > I'm not sure this really happens but... if you add startup loads to
> > > preferences through Pd venilla, then if they don't load or crash for
> > > Pd extended, this would be made more confusing if the libraries weren't
> > > visible from a dialog somewhere.
> > > 
> > > On the other hand, you could fix fix Pd extended actually to
> > > ignore "lib" preferences altogether (although respect them on the
> > > command line for 'experts' -- then it would mke sense to get rid of
> > > the dialog and perhaps people would be very grateful for the simplification.
> > > 
> > > cheers
> > > Miller
> > > 
> > > On Tue, Sep 20, 2011 at 11:58:47AM -0400, Hans-Christoph Steiner wrote:
> > > > 
> > > > Please give an example of how this would make this more confusing. My
> > > > experience is the exact opposite and it is exactly this problem that
> > > > leads me to want to remove those preferences.  The are a big source of
> > > > confusion and problems, and most Pd-extended users do not use them.  I
> > > > am not proposing removing them from Pd-vanilla, only Pd-extended.  I
> > > > think globally loading libraries is a broken idea.  
> > > > 
> > > > If you remember in the days before Pd-extended, patches that relied on
> > > > external libraries were mostly unsharable.  It could take a long time to
> > > > track down all the dependencies, etc. and you couldn't be sure which
> > > > [wrap], [split], [prepend], [scale], etc. the patch needed.  Having the
> > > > configuration in the patch means at worst you know what you need to get
> > > > it running.
> > > > 
> > > > At this point I've taught Pd to 10 year olds, high school kids, college
> > > > kids, masters students, and all sorts of people in workshops, college
> > > > courses, and patching circles.  I also answer a lot of questions on
> > > > email, on forums, and on IRC.  It is from this experience that I am
> > > > coming from on this issue.  I have no desire to control people, I do
> > > > have a strong desire to make Pd-extended very user friendly to newbies
> > > > and a excellent editing experience for advanced users.
> > > > 
> > > > And those that like the Pd-vanilla way are welcome to use it,
> > > > Pd-extended will remain compatible with patches from Pd-vanilla as long
> > > > as I work on it.  Of course, it is not possible to maintain 100%
> > > > compatibility when going from Pd-extended to Pd-vanilla since extended
> > > > includes many more objects.  There is also pd-l2ork, desiredata, etc.
> > > > for those who want different approaches.
> > > > 
> > > > .hc
> > > > 
> > > > On Tue, 2011-09-20 at 13:02 +0100, Andy Farnell wrote:
> > > > > 
> > > > > Whenever I see the words "this would _make_ people"...
> > > > > alarm bells start ringing for me.
> > > > > 
> > > > > Yes, the proposed behaviour is perfectly correct, logical,
> > > > > and consistent. And utterly the wrong thing to do IMHO.
> > > > > 
> > > > > It would frighten off newcomers and disorientate students.
> > > > > 
> > > > > It's why we create the cushion of fairy stories
> > > > > for kids, to soften the harsh realities of the 
> > > > > _actual_ world. Later on you learn that there isn't
> > > > > a magic library fairy that loads everything, but it
> > > > > helps you cope with the first steps.
> > > > > 
> > > > > If anybody made PD that broken out of the box it
> > > > > would require lots of work to fix in order to make
> > > > > it fit to teach with again.
> > > > > 
> > > > > 
> > > > >  
> > > > > > On 2011-09-19 19:32, Hans-Christoph Steiner wrote:
> > > > > > > 
> > > > > > > Hey Miller,
> > > > > > > 
> > > > > > > I actually think this would make switching between vanilla and extended
> > > > > > > easier because it would make people use [import] or [declare] to load
> > > > > > > libs, then when using vanilla, you'll know which libraries the patch
> > > > > > > needs.  Can you think of examples where it would make things more
> > > > > > > difficult?
> > > > > 
> > > > 
> > > > 
> > > > 
> > > > _______________________________________________
> > > > Pd-dev mailing list
> > > > Pd-dev at iem.at
> > > > http://lists.puredata.info/listinfo/pd-dev
> > 
> > 
> > 
> > _______________________________________________
> > Pd-dev mailing list
> > Pd-dev at iem.at
> > http://lists.puredata.info/listinfo/pd-dev