[PD] help files was: Re: call for testing on the nightly builds!

[Hans-Christoph Steiner]

On May 18, 2008, at 11:30 AM, Rich E wrote:

>
>
> On Sat, May 17, 2008 at 9:03 AM, Hans-Christoph Steiner  
> <hans at eds.org> wrote:
>
> On May 17, 2008, at 5:50 PM, Enrique Erne wrote:
>
> > Hans-Christoph Steiner wrote:
> >> There is much that can and should be done.  Here's some ideas
> >> ranked into of difficulty:
> >> - file a bug report when a help patch is not working
> >> - write and improve help patches, and submit them to the patch
> >> tracker
> >
> > is there a convention about how to make it work? i.e. should one
> > use declare, import or namespace prefix?
> >
> > i guess all help-files that are not loaded on default would need a
> > declare/import/or-namespace in order to work...
> >
> > i want to contribute and help to make "all"/more helpfiles work. i
> > know there is pddp but afaik it does not solve the declare/import/
> > or-namespace problem.
> >
> > could all developers express their opinion and agree on how to make
> > all helpfiles work? :)
>
> Starting with the PDDP template is a good place to start:
>
> http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/doc/pddp/
> templates/
>
> > i'm not a developer but i would vote for declare
> > i.e. [declare -stdlib mrpeach] to packOSC-help.pd
> > then it would work with pd vanilla too.
>
> This isn't working for me, using the latest pd-extended.  When I  
> start pd with the '-verbose' flag and then use a [declare]  
> statement, what I am declaring is not getting searched (or at least  
> it isn't posting that it is.  Anyways, the object in that directory  
> isn't found).

With the current [declare], you would need to do

[declare -stdlib /full/path/to/mrpeach]
[declare -stdpath /full/path/to/mrpeach]

.hc

>
> I think this would be a good approach, similar to python's "from x  
> import *" mechanism, but probably not good for help files, as they  
> could introduce nameclashes that are avoided with namespaces.
>
> Personally, I would use namespace prefixes:   [mrpeach/packOSC].
> This will make more sense when there are libraries organized around
> concepts rather than authors.  So something like [osc/packOSC]
>
> This seems appropriate for help files, as it also tells you where  
> to find the object within the extra folder.  Sort of self-documenting.
>
>
>
> >> - add a search pane to the help panel
> >
> > is this done in tcl/tk? is there any documentation about that on
> > puredata.info?
>
> It is done however you want to, more or less, but I think a pure Tcl
> solution would be possible, and perhaps easiest.
>
> .hc
>
>
> >
> >
> >
> >
> >
> >> - help design and code a library format that bundles
> >> objectclasses, helpfiles, manuals, examples, etc then write code
> >> to index it all, and create a GUI to navigate that content
> >> At this point, I think it is mostly a waste of time to do constant
> >> little workarounds like moving around objects.  We should be
> >> putting our scarce resources towards real improvements, not
> >> temporary fixes, IMHO.
> >> .hc
> >>
>
>
>
> ---------------------------------------------------------------------- 
> --
> ----
>
> News is what people want to keep hidden and everything else is
> publicity.          - Bill Moyers
>
>
>
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
> listinfo/pd-list
>



------------------------------------------------------------------------ 
----

If nature has made any one thing less susceptible than all others of  
exclusive property, it is the action of the thinking power called an  
idea, which an individual may exclusively possess as long as he keeps  
it to himself; but the moment it is divulged, it forces itself into  
the possession of everyone, and the receiver cannot dispossess  
himself of it.            - Thomas Jefferson


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20080519/5650b592/attachment.htm>