No subject

documentation, because the source doesn't tell you what it's supposed to=20
be doing, instead it tells you what it does.

I'm not sure what you mean about the headers... pd classes don't need to=20
be declared with .h files, so most libraries don't have any.

There was some talk about picking up runtime info from classes, such that=
=20
a documentation edition system could tell you things like : canvas is=20
missing documentation for method "bounds" and it has four f-arguments.
But it wouldn't work all of the time : e.g. for GridFlow, it would look=20
like there is a single anything-method taking unlimited unchecked args.
Same for all other cross-language interfaces that use class_addanything a=
s=20
little as possible.

> You are right. Voting is not a good solution. However, neither is the=20
> position of "my format or the highway". However, I suppose it was a=20
> mistake to say that we should all have a =A0graphical template to follo=
w=20
> and to change all existing help files to it.

I believe in the separation of content and presentation. This has been a=20
major transformation in the world of web since HTML4/CSS, and eventually=20
took root deep into many web frameworks of the decade. It's not a web=20
invention either. It was also deep in the SmallTalk 1980 GUI toolkit,=20
where much of the inspiration came from. In Pd it's not really possible t=
o=20
do the separation, as coordinates are written all over the file format,=20
but the least I can do is make it so that you don't have to position the=20
objects yourself... most of the time.

> If I was in your position, I wouldn't want to migrate without a good=20
> reason. After all, we all patch differently, we use PD because we love=20
> the freedom in how we can work.

It's not just for myself. I believe that the ideas I am putting forward=20
for documentation, are essentially good for everybody.

> One possible solution would be that we can at least agree upon what hel=
p=20
> patches should contain (argument lists, inlet/outlet descriptions etc)=20
> and not bother with exact format of "this text goes here, this canvas=20
> header is this big and this color, =A0etc".

Let's bother about it, but let's bother about it separately. Layout and=20
colours can go in abstractions where you can change the look of all=20
helpfiles at once (to the extent that the automation has been done. in=20
GridFlow it's perhaps 90% there). The first problem I see with not having=
=20
a separation, is that people want to finish deciding the look so that the=
y=20
can start writing the docs because once you do it, it's really hard to=20
change the look. That's why PDDP meetings introduced a receive-symbol for=
=20
changing the colours ; but it didn't introduce abstractions, which are a=20
much more powerful way to deal with the matter.

> I remember making the point at PdCon07 that the help browser was=20
> confusing to use and I couldn't find the information I wanted (help,=20
> references) without going through each folder. A number of people gave=20
> me a dismissive look and I don't remember the responses I was given, bu=
t=20
> they were more along the lines of "it's all there, can't you see?". I=20
> got the feeling that since it wasn't a problem for those that had=20
> learned the locations of the objects and their names, then it wasn't a=20
> problem worth solving. That it was my fault and I should just read more=
.=20
> This did not and still does not sit well with me.

So, what were the solutions that you were proposing, or would have been=20
proposing, or what are the elements of the problem that suggest what kind=
=20
of solution it could be ?

> As far as I know, the pd gui rewrite adds the ability for custom tcl/tk=
=20
> snippets through the command menu. This could be just a tcl call to svn=
=20
> diff.

Ok, so, you have to hunt all over the internet for pieces of tcl code tha=
t=20
take 1k each ? Pd has this concept of externals, that are rather=20
plug-and-play (or at least: can be), and then Pd-extended changed the dea=
l=20
and made it no-plug-just-play, and then Pd-devel ("gui-rewrite") would=20
have those snippets of tcl floating around so that you can download your=20
menu-items one by one ? A little bundling would help...

what's the "command menu" ?

> Good point. If discussions are not public, we are not obligated to both=
=20
> share and defend our ideas or viewpoints.

Well, it's also that pdpedia is hard to defend. I expect pdpedia to be=20
replaced by something else soon.

> In doing so, one has to really give thought into what one is doing.

To give more thought into what one is doing, you need prototypes. Talking=
=20
and thinking doesn't make one realise all the faults like a prototype=20
does. Discussion better be built around prototypes than what-ifs.

> To me, it's the difference between to stating an idea then coding it=20
> directly and stating an idea, researching it, presenting it others,=20
> getting feedback, and then coding it.

It's a good idea to think about the ability for a design to evolve. That=20
way you can make a prototype early without feeling too guilty about it,=20
and from the prototype you get much feedback that you wouldn't get from=20
conversations, and then you can recycle the prototype into a more=20
long-lasting solution (which would be why you wouldn't be guilty to code=20
early, and why the design ought to be evolvable).

> If we don't collaborate effectively, I feel we waste effort=20
> individually.

I've come to think of the default as being no collaboration at all, and=20
look at effective collaboration as a form of saving. It's more positive=20
and it conveniently removes the myth of a most perfect collaboration from=
=20
the equation. The amount of waste is the distance between where we stand=20
and the utmost bestest solution we can't even think of. Frustration=20
doesn't come from this waste, it comes from measuring this waste. In the=20
end, much of this waste doesn't even exist, or assumes unacceptable=20
tradeoffs involving unstated requirements (or otherwise ignored=20
requirements).

> Also, we as a community look less active which, for an open source stan=
d=20
> point, is not good.

Why would that be, according to you ?
I mean why is the community looking less active...

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard, Montr=E9al, Qu=E9bec. t=E9l=E9phone: +1.514.383.3801
--751927920-2064080110-1275793642=:12043--