--- On Tue, 12/14/10, Mathieu Bouchard <ma...@artengine.ca> wrote:
> From: Mathieu Bouchard <ma...@artengine.ca> > Subject: Re: [PD] libraries in Pd-extended 0.43 > To: "Jonathan Wilkes" <jancs...@yahoo.com> > Cc: "PD List" <pd-list@iem.at>, "Hans-Christoph Steiner" <h...@at.or.at> > Date: Tuesday, December 14, 2010, 3:04 AM > On Mon, 13 Dec 2010, Jonathan Wilkes > wrote: > > > As far as improving documentation, I'd say every > object in Pd-ext should be > > documented clearly in a help patch that outlines: > > I'd say every class in Pd-ext should be > documented clearly in a help patch that outlines: You're right. I'm an object-o-phile. But do you find "Related Objects" troubling-- should it be "Related Classes"? > > > 1) what the object does > > 1) what the class does In a lot of situations you need both. For something like canvas_class it doesn't make much sense to put all the details of "what the class does" in one giant help file-- for instance, to follow your GFDP model, you'd have one "see also" section that includes [inlet] (which relates to [pd] but not to [table]) as well as [tabread] or the "Put" menu array (vice versa). So you can have one help patch for the class that has links to individual objects. > > > 5) any related objects (esp. internal objects) > > 5) any related classes (esp. internal classes) Ok so you do think it should say related classes. -Jonathan > > > _______________________________________________________________________ > | Mathieu Bouchard ---- tél: +1.514.383.3801 ---- > Villeray, Montréal, QC _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list