On Wed, 06 Jul 2011 18:52 +0200, "András Murányi" <[email protected]> wrote: > 2011/7/6 Hans-Christoph Steiner <[email protected]> > > > On Wed, 06 Jul 2011 15:32 +0200, "András Murányi" <[email protected]> > > wrote: > > > 2011/7/3 Hans-Christoph Steiner <[email protected]> > > > > > > > > > > > On Jul 3, 2011, at 10:04 AM, András Murányi wrote: > > > > > > > > On Sat, Jul 2, 2011 at 20:41, Hans-Christoph Steiner <[email protected] > > >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.
Yes, I agree. For things that affect the editor and not the patch itself, then preferences makes more sense. .hc _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
