--- On Sun, 12/19/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: Sunday, December 19, 2010, 1:54 AM > On Tue, 14 Dec 2010, Jonathan Wilkes > wrote: > > > Yeah, so currently I have links inside canvas-help.pd > to table-help.pd, pd-help.pd, graph-help.pd, and a special > note about "Put" menu arrays with a link to > array-help.pd. array-help.pd is necessary to have > there because triggering the help patch for the "Put" menu > array is so obscure (I wonder if anyone here even knows what > to click to get it.) > > I don't know how you can possibly not get it. That's probably because you've never gotten it. Clicking on the graph that contains the array opens up 'canvas-help.pd'. But you can open a help patch named 'array-help.pd' when you: a) right-click on the "Put" menu array and choose "Open", b) mouse-over an array element until the arrow cursor changes directions, c) right-click and choose help. Then you will receive enlightenment from Pd's generous help docs: sorry, couldn't find help patch for "array.pd" Though it's certainly to the point, I thought a user might want a tad bit more information than that, so I made an array-help.pd patch, and linked to it in canvas-help.pd for those few boring users who choose not to click random spots within a patch until something helpful and relevant happens. -Jonathan > Do you expect > that you can get it by right-clicking the array's label ? > Because, it doesn't work for any other label (IEMGUI...), > so, why would it work for Array's label ? > > > That's true, but just because it's possible to do that > doesn't mean that [inlet] and [outlet] are relevant enough > to show in the help patch for [table], any more than showing > [list] in the help patch for [metro]. > > Also, it doesn't work the other way around-- > [tabread], [tabwrite], etc. are not relevant to [pd]. > > Actually, when you have a [table], you don't have one > object, you have two of them. Three of them. There's also a graph within the table. > When you have [table foo], > receive-symbol "pd-foo" sends to a canvas, whereas > receive-symbol "foo" sends to the internal t_array object, > which has all of the array-specific methods. This has to be > made clear, because it's not like an inheritance-like > pattern. > > An inheritance-like pattern (or interface pattern) would > be, for example, to have one single help-patch for most of > the common methods in iemguis, those that have exactly the > same behaviour, to emphasise that they are one single family > (even though inheritance in pd is mostly in our > imagination). It's a matter of documenting things in a > non-repetitive, synthetic manner, and with a mindset that > encourages consistency. How do you make that system of documentation consistent across libraries? (And show links across libraries?) > > When you have one class that seemingly would include one > complete other helpfile's content but not the other way > around, that would usually be an inheritance pattern, but > it's not here, because instead, it's mostly that a canvas > has a t_array tacked onto it, vs not. > > It can't be called delegation pattern either, because in a > delegation pattern, you have two objects, of which you only > send to one, which will forward the message to the other one > whenever appropriate. This is not the case here, because you > can send to two different receive-symbols, and you have to > send to the correct one. > > I could have said a lot less, but I just thought I'd give > you some more doc ideas. > > > _______________________________________________________________________ > | 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