This does bring up the issue in the deployment plan for such "help" menu features. I figure we should have consensus on a plan for what to do and then figure out what steps in what order to develop it slowly.
As a quick and easy point in the right direction I think HC's idea is fine in the short term. The problem with the idea is that I would argue the doc/ structure leaves a lot to be desired as an interface to documentation for an end user.
If we could reuse the code used to decent into the doc/ tree then it would help, if there is not other use for this in the short term...
Oh there is some tcl code for decending into a directory tree in LML (no longer maintained -
www.ekran.org/ben/research/lml/lml-v0.1-TEST8-linux.tgz
May be useful for something.
Ok, onto other emails in this thread, ug!
I think I'll have to sum up the comments and respond in one big email.
B>
Hans-Christoph Steiner wrote:
On Apr 25, 2005, at 8:00 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
I think the auto-generated menu should just recurse thru doc/ and mirror that structure in the menu structure. Its not a great solution, but better that what's there.
why ? in my opinion, the doc/ is pretty much fixed (after packaging).
additional libraries and externals are normally installed into extra/ (or wherever additional "path"s point to) since p>=0.37 help can be installed besides them and will still get found.
these are the real problematic (and interesting) objects to auto-index. (i mean, for the fixed objects in doc/, we can build an offline (this is: packaging-time) index.
mfg.a.dsr IOhannes
Because its easy, its almost done, and its a temporary hack.
.hc
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev