ciao frank
On Mon, 2006-08-21 at 08:48 +0200, Frank Barknecht wrote:
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
since the helppatches cannot be reached from the helpbrowser, when they are located in pd/extra,
This must be another bug of the help browser: It doesn't seem to care about user-settings regarding -help-path.
for me it is not obvious that the helpbrowser is suppoesed to show all -helppathes, but i am not the developer of it and therefore cannot tell what it is intended to do. a statement on that from the developer would be nice (miller?). but i think such a feature would solve a lot problems.
I don't think the location of the help-patches should be used to get an overview of the objects in a library. There is no direct connection between these two attributes, it would be artificial and error prone to create one IMO. Still for making installation and packaging easier, subdirs for every library have advantages.
of course, it would be error prone, but what other way is there to find out all the objects of a certain library? i see only two ways: looking into the helppatches or visiting the website of the external, if there is one (not having the possibility in pd itself to view the content of an external is kind of awkward, IMO)
from the users point of view the following points would make life easy:
- helppatches of the libs are located in pd/doc/5.refernece/<lib>
Possible. pd-extended generally works that way IIR. However you need to use pd-extended's "-libdir" extension (or is this already in 0.40) to make it work when using directory prefixes.
'possible' is not the answer i was looking for. finally i don't care much, where the helppatches are located, but it would be nice if there is a standard and if developer of externals would follow that standard. the situation as it is now is not quite satisfying from a users point of view.
the only problem i see here, is that one has to add an extra -helppath for each lib. it would be nice, if that could be avoided by searching pd/doc/5.reference recursively.
No, this would break a lot of things, especially directory prefixed names like [maxlib/scale].
i see, although this is only a problem in pd-extended, afaik. that means there is no other way than having to add an extra -helppath for each external. since the good ol' .pdrc has been considered to be deprecated many times , iirc, and i couldn't find a way to add a -helppath through the menu, this concept seems to be problematic.
For my abstractions I like to keep it simple and I just place the help patches next to the original abstractions.
this is a nice approach, imo.
NB: I think, we should not try to organize the file layout by looking at the current help browser. IMO the browser has a broken design, because it's just a filebrowser limited to a certain directory, and it's a worse filebrowser than the builtin Tk filebrowser was. A real help browser should look different anyways. What I have seen in DesireData is going in the right direction IMO, but it's a radical change, os don't hold your breath.
i am just looking for a good way to organize the helppatches. it seems that now everybody just fights him/herself through this jungle on its own... ;-)
ciao roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de