[PD] installatation path of help-files
hans at eds.org
Tue Apr 15 21:28:07 CEST 2008
The core idea of libdirs is to have everything put into one
directory, so all have to do to install a library is drop the folder
into a directory that is in the path, then the objects, the help
files, the examples, and the manuals will all show up in the right
place, and you'll be able to load the library with [import], and use
This means rewriting the help browser to use generated lists of files
rather than just showing the file layout. Basically the rest is
Any help would be appreciated, if someone wants to take on a chunk of
this problem, like writing the help browser support. But I don't
plan on talking about it this much more since we have done a ton of
talking on this topic. Now we need doing. Then we can talk again
after we have done something to make sure it is good :)
On Apr 15, 2008, at 1:53 PM, marius schebella wrote:
> oops, so then all the mess comes from pd-extended...
> maybe we should differentiate between "normal" external behaviour and
> pd-extended behaviour that could actually be different because it
> recompiles the externals and also can relocate help-patches in its
> own way.
> the "normal" way would be to allow the developer to put her files
> wherever she wants. and come up with an individual installation method
> and probably the need to add a path and lib flag to the startup script
> for every external.
> but in pd-extended it should only be necessary to add startup flags
> additional libraries that are not already included in pd-ext (like
> or some flext externals). and therefor I think the pd-ext installation
> paths should be uniform, either all into library subfolders or none.
> one problem remaining is that some help-file paths seem to be
> in the externals, which I think is not a good idea?
> IOhannes m zmoelnig wrote:
>> marius schebella wrote:
>>> I think the whole help browser stuff is very messy. there is
>>> "1.manual" versus "manuals" "media" vs "sound" and "7.stuff" versus
>>> "examples" some of the stuff is pd patches, some are textfiles, some
>>> are html docs.
>> that is interesting, i just have:
>> which is not that badly organized :-)
>>> I think all html or text manuals should be in a separate section of
>>> the help menu, not in the browser (in pd-extended there already is a
>>> html menu-entry)
>>> 2.-4.and 6.(although, I am not sure about 6.) should be in a
>>> 5. reference should be called "help-patches"
>> what makes "help-patch" better than "reference"?
>> most of pd's help patches are really "references", especially if you
>> browse it via the menu (a help-patch is the thing you open via right
>> mouseclick; a reference is the thing you browse)
>>> sound should be a part of media.
>>> then you get
>>> --- HTML
>>> --- --- Pd
>>> --- --- Gem
>>> --- --- (other manuals)
>>> --- BROWSER
>>> --- --- Tutorials
>>> --- --- --- (control examples)
>>> --- --- --- (audio examples)
>>> --- --- --- (data structures)
>>> --- --- --- (external tutorials??)
>>> --- --- Examples
>>> --- --- --- soundfile tools
>>> --- --- --- synths ...
>>> --- --- --- (tidied up content of 7.stuff)
>>> --- --- --- (tidied up content of examples)
>>> --- --- Help Patches
>>> --- --- Media
>>> --- --- --- images and video
>>> --- --- --- sounds
>>> --- --- --- obj., mtl. ...
>> for me (if i understand your proposal correctly), this only makes
>> if objects would be grouped by function rather than by library.
>> this seems to have been unfeasible to do in the last year.
>> i think we should take practice into account.
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously. - Benjamin Franklin
More information about the Pd-list