[PD] scripts instead of preferences WAS: reorg of puredata.info/docs/developer

[András Murányi]

2011/7/6 Hans-Christoph Steiner <hans at at.or.at>

> On Wed, 06 Jul 2011 15:32 +0200, "András Murányi" <muranyia at gmail.com>
> wrote:
> > 2011/7/3 Hans-Christoph Steiner <hans at at.or.at>
> >
> > >
> > > On Jul 3, 2011, at 10:04 AM, András Murányi wrote:
> > >
> > > On Sat, Jul 2, 2011 at 20:41, Hans-Christoph Steiner <hans at at.or.at
> >wrote:
> > >
> > >>
> > >> I just finished a big, long-overdue reorg of the
> > >> http://puredata.info/docs/**developer<
> http://puredata.info/docs/developer>section of the website.
> > >>
> > >>  * Its now a "wiki folder" so it acts like a regular wiki, not like a
> > >> weird plone mix of things.  It also allows email subscripts to wiki
> pages.
> > >>
> > >>  * I purged old pages and redirected them to the new versions
> > >>
> > >>  * I cleaned up the formatting on the front page
> > >>
> > >>  * I updated references to CVS, etc.
> > >>
> > >>  * I purged a couple very out-of-date things
> > >>
> > >> Let me know what you think, and please contribute where you can! :-D
> > >>
> > >> .hc
> > >>
> > >>
> > > IMHO the whole GUI Plugins stuff could go under Developer.
> > >
> > >
> > > One goal for me is to make it easy enough for all Pd users to write
> their
> > > own GUI plugins.  Honestly, I think we can make GUI plugins replace the
> idea
> > > of preferences.  A simple set of preferences is very easy to
> understand.
> > >  But many people find a simple set limiting, so you see many programs
> > > implementing huge preferences systems that mystify most users (think
> > > Photoshop, MS Office, OpenOffice, etc.)  I think with a well designed
> > > scripting/plugin system, it would work better than preferences.
> > >
> > > .hc
> > >
> >
> > Understood. However, I think plugins can never replace preferences as
> > they
> > are two different things. Plugins need to save their data somewhere too,
> > and
> > that somewhere is the preferences. If the file format of preferences was
> > something programmatic (ie. not "loadlib9: moonlib" but "variable
> > loadlib9
> > 'moonlib'" or something like that) there would be more change for a
> > convergence, but at the same time the format would be less easy to
> > parse/write/etc. So at the end, preferences are data, and plugins are
> > programs, and that's how it's good.
> > But, I understand and agree that you want to bring plugins closer to the
> > users and that that's why plugin docs won't go under developer docs.
> >
> > Andras
>
> In the context of a programming environment, I don't see a lot of reason
> to have a separate preferences system.  Things like configuring the
> audio and MIDI interface are usually best handled in the patch, and that
> should be as easy as possible.  IOhannes has made big progress there
> with the 'mediasettings' library.  Things like loading libraries should
> definitely be done in the patch and not globally.  Just look at python,
> ruby, java, C++, C, etc. etc. etc for examples there.
>
> What I'd like to see is a standard Pd patch that is loaded in the place
> of preferences.  Then you could configure your Pd setup using a Pd
> patch.  Any Pd user is going to know how to make a patch, so if you can
> configure Pd with a Pd patch, then you don't need to learn any new
> preferences file format or system.
>
> hc
>

OK, sounds good. But let's just remember the use case when we want pd to
remember which plugins to load and which not. As plugins load before any
patch, and they couldn't really be enabled/disabled per patch, their
preferences will have to be stored somewhere else. We agreed before that the
"/disabled" folders method is no good, and that we (probably me) will code
up a logic which stores this in preferences (via ::pd_guiprefs). I'm
interested in further brainstorming but right now I feel that good old
preferences is something we'll have to live with for a longer time. We'll
have to make a distinction between global stuff (plugins, global prefs) and
those things which are better handled per patch, from inside patches.

Andras
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20110706/2ededf10/attachment.htm>