--- On Sun, 12/19/10, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] libraries in Pd-extended 0.43 To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "PD List" pd-list@iem.at, "Hans-Christoph Steiner" hans@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