hi all
bravely i tried to clean the mess i have with all the help-patches lying in different places and came to the conclusion, that there is no obvious way to do it right now. although i use pd for at least two years now, several things are still unclear to me (and maybe to others, too):
- what is the 'offical' (non-deprecated) naming-scheme for help-patches:
help-<name>.pd, <name>-help.pd or just <name>.pd (the last seems not to work, but i found some helppatches named after this scheme) since pd's own helppatches are named after <name>-help.pd, i assume this the 'official' one.
- where are they supposed to be?
i found helppatches in the following locations (i didn't place them by myself, they all have been put there by their installers)
- pd/extra/
- pd/extra/<lib>/
- pd/doc/5.reference/
- pd/doc/5.reference/<lib>/
- pd/doc/<lib>/
- pd/doc/<lib>/<blablablabl>/<blablabl>/
since the helppatches cannot be reached from the helpbrowser, when they are located in pd/extra, i'd say this is not the way to go. it's handy to have an overview of all objects of a certain lib. also would it be nice to have the helppatches of the libs separated from pd's own helppatches.
from the users point of view the following points would make life easy:
-all helppatches are named after <name>-help.pd, which makes browsing easier
- pd's own helppatches are located in pd/doc/5.reference (as it is now)
- helppatches of the libs are located in pd/doc/5.refernece/<lib>
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.
i didn't find any documentation about this topic and i intentionally did not search the archives, since i'd like to have this discussion come to a final conclusion. the above can be considered just as a starting point.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
- what is the 'offical' (non-deprecated) naming-scheme for help-patches:
help-<name>.pd, <name>-help.pd or just <name>.pd (the last seems not to work, but i found some helppatches named after this scheme) since pd's own helppatches are named after <name>-help.pd, i assume this the 'official' one.
It was agreed that <name>-help.pd is preferred scheme. This way you still get a kind of alphabetic order instead of all files starting with "help-" and you could in priciple use the keyboard to navigate a help browser (worked with the old one, but doesn't work with the one currently called help browser).
- where are they supposed to be?
i found helppatches in the following locations (i didn't place them by myself, they all have been put there by their installers)
- pd/extra/
- pd/extra/<lib>/
- pd/doc/5.reference/
- pd/doc/5.reference/<lib>/
- pd/doc/<lib>/
- pd/doc/<lib>/<blablablabl>/<blablabl>/
^ 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.
i'd say this is not the way to go. it's handy to have an overview of all objects of a certain lib. also would it be nice to have the helppatches of the libs separated from pd's own helppatches.
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.
from the users point of view the following points would make life easy:
-all helppatches are named after <name>-help.pd, which makes browsing easier
Yes, definitely
- pd's own helppatches are located in pd/doc/5.reference (as it is now)
Good.
- 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.
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].
For my abstractions I like to keep it simple and I just place the help patches next to the original abstractions. This way I directly see which abstraction are still without help-patch. For "installing" these patches I think, the libdir approach makes the most sense.
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.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
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
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
On Mon, 2006-08-21 at 08:48 +0200, Frank Barknecht wrote:
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)
Looking at the help patch will only give you a list of help patches. Many objects especially abstractions miss help files, while some help files may not be for single objects (like "otherbinops-help.pd").
A better aproach is the class browser in DesireData which I mentioned.
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.
Recursively added help-paths would also break stuff or at least create confusion on standard Pd. For example, assuming you have a help patch for maxlib/scale-help.pd and Gem/scale-help.pd. Which one should be used when you look for help on [scale]?
A solution could be directory namespaces.
This would work for exmaple if you have a collection of patches in a directory "netpd" and if you will always use them with the directory prefix "netpd/".
So for example your "netpd" directory is in "mystuff", you have "mystuff/netpd/run.pd" and "mystuff/netpd/run-help.pd" inside which calls and explains [netpd/run]. Then you add this to .pdrc/pdsettings:
-path mystuff -helppath mystuff
and all is well. Now exchange "mystuff" with "/usr/lib/pd/extra" and it gets even easier.
However you won't be able to easily omit the "netpd/"-prefix now and simply use [run] unless you use pd-extended, because either Pd will have a hard time finding the correct help file or your help-file will have problems finding the object it is intended for. Just try it.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Mon, 2006-08-21 at 15:59 +0200, Frank Barknecht wrote:
Looking at the help patch will only give you a list of help patches.
yeah, you are right, it's better to look into the abs-directory itself. but when exploring freshly installed externals, i usually have a quick view on the list of helpfiles, just to get an idea... objects that miss helpfile probably will never be used by me, since i don't know how they work anyway....
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.
Recursively added help-paths would also break stuff or at least create confusion on standard Pd. For example, assuming you have a help patch for maxlib/scale-help.pd and Gem/scale-help.pd. Which one should be used when you look for help on [scale]?
i don't understand your point here. let's say you have '-lib Gem:maxlib -helppath /to/gem/helpfiles -helppath to/maxlib/helpfiles'. first you don't know which [scale] is used when instanciated, then you still don't know which helpfile is loaded on right-click->help.
A solution could be directory namespaces.
this is only a solution for abs, but not for externals, yet. and the fact that pd-extended uses dir-namespaces doesn't make things easier, since it breaks 'interchangeability' of patches between pd-extended and pd.
This would work for exmaple if you have a collection of patches in a directory "netpd" and if you will always use them with the directory prefix "netpd/". So for example your "netpd" directory is in "mystuff", you have "mystuff/netpd/run.pd" and "mystuff/netpd/run-help.pd" inside which calls and explains [netpd/run]. Then you add this to .pdrc/pdsettings:
-path mystuff -helppath mystuff
i just found out, that when the helppatches are located in the same dir as the abs, specifying only the -path works for helpfiles, too. this makes your way - putting the helpfiles together with the abs - even more usefull.
well, since i talked only with you, frank, may i ask you, how you organize your stuff, just as an example? do you leave the helpfiles, where the install-script has put them? or do you place them altogether somewhere?
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
I also am curious as to how Frank organizes his stuff, since it seems that he has so much of it!
~Kyle
On 8/21/06, Roman Haefeli reduzierer@yahoo.de wrote:
On Mon, 2006-08-21 at 15:59 +0200, Frank Barknecht wrote:
Looking at the help patch will only give you a list of help patches.
yeah, you are right, it's better to look into the abs-directory itself. but when exploring freshly installed externals, i usually have a quick view on the list of helpfiles, just to get an idea... objects that miss helpfile probably will never be used by me, since i don't know how they work anyway....
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.
Recursively added help-paths would also break stuff or at least create confusion on standard Pd. For example, assuming you have a help patch for maxlib/scale-help.pd and Gem/scale-help.pd. Which one should be used when you look for help on [scale]?
i don't understand your point here. let's say you have '-lib Gem:maxlib -helppath /to/gem/helpfiles -helppath to/maxlib/helpfiles'. first you don't know which [scale] is used when instanciated, then you still don't know which helpfile is loaded on right-click->help.
A solution could be directory namespaces.
this is only a solution for abs, but not for externals, yet. and the fact that pd-extended uses dir-namespaces doesn't make things easier, since it breaks 'interchangeability' of patches between pd-extended and pd.
This would work for exmaple if you have a collection of patches in a directory "netpd" and if you will always use them with the directory prefix "netpd/". So for example your "netpd" directory is in "mystuff", you have "mystuff/netpd/run.pd" and "mystuff/netpd/run-help.pd" inside which calls and explains [netpd/run]. Then you add this to .pdrc/pdsettings:
-path mystuff -helppath mystuff
i just found out, that when the helppatches are located in the same dir as the abs, specifying only the -path works for helpfiles, too. this makes your way - putting the helpfiles together with the abs - even more usefull.
well, since i talked only with you, frank, may i ask you, how you organize your stuff, just as an example? do you leave the helpfiles, where the install-script has put them? or do you place them altogether somewhere?
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
On Mon, 2006-08-21 at 15:59 +0200, Frank Barknecht wrote:
A solution could be directory namespaces.
this is only a solution for abs, but not for externals, yet. and the fact that pd-extended uses dir-namespaces doesn't make things easier, since it breaks 'interchangeability' of patches between pd-extended and pd.
Well, the interchangeability indeed is a problem, but not that much, if one decides to actually only use dir-namespaces. Because of the problems with finding help-files I'm a bit reluctant to use them already, but I plan to do so in the near future.
Btw: Directory namespaces also work for externals, just like they do for abstractions. There is no difference except when dealing with real libraries that bundle multiple externals, like Gem.
This would work for exmaple if you have a collection of patches in a directory "netpd" and if you will always use them with the directory prefix "netpd/". So for example your "netpd" directory is in "mystuff", you have "mystuff/netpd/run.pd" and "mystuff/netpd/run-help.pd" inside which calls and explains [netpd/run]. Then you add this to .pdrc/pdsettings:
-path mystuff -helppath mystuff
i just found out, that when the helppatches are located in the same dir as the abs, specifying only the -path works for helpfiles, too. this makes your way - putting the helpfiles together with the abs - even more usefull.
Yes, this is the standard way. Pd looks for help files basically in two places: Next to the abstraction or external and then in the directories specified in the help-path. doc/5.reference is automatically included in the help-path. The name of the help-file search is "help-NAME.pd", "NAME-help.pd", "NAME.pd" or whatever the author of a binary object specified in the source code (e.g. the help for [>] is specified as "otherbinops-help.pd")
Now if "netpd/run" from above is something with a directory, like "netpd/run", then Pd will search for "help-netpd/run.pd", "netpd/run-help.pd" or "netpd/run.pd". In this case, only the file "netpd/run-help.pd" makes sense to have.
well, since i talked only with you, frank, may i ask you, how you organize your stuff, just as an example? do you leave the helpfiles, where the install-script has put them? or do you place them altogether somewhere?
I leave them where "make install" puts them. If "make install" doesn't install the help files (for example "expr-help.pd" isn't or wasn't installed by "make install") I just put the help in doc/5.reference.
My own abstractions have their help-files right next to the original abstraction, using the NAME-help.pd pattern. I'm still not sure how to properly deal with directory prefixes later.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
wow, this mail contains a lot of useful info, and a lot of it i didn't know before. many thanks.
roman
On Tue, 2006-08-22 at 02:02 +0200, Frank Barknecht wrote:
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
On Mon, 2006-08-21 at 15:59 +0200, Frank Barknecht wrote:
A solution could be directory namespaces.
this is only a solution for abs, but not for externals, yet. and the fact that pd-extended uses dir-namespaces doesn't make things easier, since it breaks 'interchangeability' of patches between pd-extended and pd.
Well, the interchangeability indeed is a problem, but not that much, if one decides to actually only use dir-namespaces. Because of the problems with finding help-files I'm a bit reluctant to use them already, but I plan to do so in the near future.
Btw: Directory namespaces also work for externals, just like they do for abstractions. There is no difference except when dealing with real libraries that bundle multiple externals, like Gem.
This would work for exmaple if you have a collection of patches in a directory "netpd" and if you will always use them with the directory prefix "netpd/". So for example your "netpd" directory is in "mystuff", you have "mystuff/netpd/run.pd" and "mystuff/netpd/run-help.pd" inside which calls and explains [netpd/run]. Then you add this to .pdrc/pdsettings:
-path mystuff -helppath mystuff
i just found out, that when the helppatches are located in the same dir as the abs, specifying only the -path works for helpfiles, too. this makes your way - putting the helpfiles together with the abs - even more usefull.
Yes, this is the standard way. Pd looks for help files basically in two places: Next to the abstraction or external and then in the directories specified in the help-path. doc/5.reference is automatically included in the help-path. The name of the help-file search is "help-NAME.pd", "NAME-help.pd", "NAME.pd" or whatever the author of a binary object specified in the source code (e.g. the help for [>] is specified as "otherbinops-help.pd")
Now if "netpd/run" from above is something with a directory, like "netpd/run", then Pd will search for "help-netpd/run.pd", "netpd/run-help.pd" or "netpd/run.pd". In this case, only the file "netpd/run-help.pd" makes sense to have.
well, since i talked only with you, frank, may i ask you, how you organize your stuff, just as an example? do you leave the helpfiles, where the install-script has put them? or do you place them altogether somewhere?
I leave them where "make install" puts them. If "make install" doesn't install the help files (for example "expr-help.pd" isn't or wasn't installed by "make install") I just put the help in doc/5.reference.
My own abstractions have their help-files right next to the original abstraction, using the NAME-help.pd pattern. I'm still not sure how to properly deal with directory prefixes later.
Ciao
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On Aug 21, 2006, at 11:18 PM, Roman Haefeli wrote:
On Mon, 2006-08-21 at 15:59 +0200, Frank Barknecht wrote:
Looking at the help patch will only give you a list of help patches.
yeah, you are right, it's better to look into the abs-directory
itself. but when exploring freshly installed externals, i usually have a quick view on the list of helpfiles, just to get an idea... objects that
miss helpfile probably will never be used by me, since i don't know how
they work anyway....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.Recursively added help-paths would also break stuff or at least
create confusion on standard Pd. For example, assuming you have a help patch for maxlib/scale-help.pd and Gem/scale-help.pd. Which one should be used when you look for help on [scale]?i don't understand your point here. let's say you have '-lib
Gem:maxlib -helppath /to/gem/helpfiles -helppath to/maxlib/helpfiles'. first you don't know which [scale] is used when instanciated, then you still
don't know which helpfile is loaded on right-click->help.A solution could be directory namespaces.
this is only a solution for abs, but not for externals, yet. and the fact that pd-extended uses dir-namespaces doesn't make things easier, since it breaks 'interchangeability' of patches between pd-extended
and pd.
Directory namespaces work in all versions on Pd, this was not
something that was added in Pd-extended. It just takes advantage of
them. And this works fine for single-class, single-file externals.
Just the multi-class, single-file libraries would have problems, but
many of us consider those deprecated.
.hc
This would work for exmaple if you have a collection of patches in a directory "netpd" and if you will always use them with the directory prefix "netpd/". So for example your "netpd" directory is in "mystuff", you have "mystuff/netpd/run.pd" and "mystuff/netpd/run-help.pd" inside which calls and explains [netpd/run]. Then you add this to .pdrc/pdsettings:
-path mystuff -helppath mystuff
i just found out, that when the helppatches are located in the same
dir as the abs, specifying only the -path works for helpfiles, too. this makes your way - putting the helpfiles together with the abs - even
more usefull.well, since i talked only with you, frank, may i ask you, how you organize your stuff, just as an example? do you leave the helpfiles, where the install-script has put them? or do you place them altogether somewhere?
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http:// messenger.yahoo.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
http://at.or.at/hans/
On Aug 21, 2006, at 8:48 AM, Frank Barknecht wrote:
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
- what is the 'offical' (non-deprecated) naming-scheme for help-
patches: help-<name>.pd, <name>-help.pd or just <name>.pd (the last seems
not to work, but i found some helppatches named after this scheme) since pd's own helppatches are named after <name>-help.pd, i
assume this the 'official' one.It was agreed that <name>-help.pd is preferred scheme. This way you still get a kind of alphabetic order instead of all files starting with "help-" and you could in priciple use the keyboard to navigate a help browser (worked with the old one, but doesn't work with the one currently called help browser).
- where are they supposed to be?
i found helppatches in the following locations (i didn't place
them by myself, they all have been put there by their installers)
- pd/extra/
- pd/extra/<lib>/
- pd/doc/5.reference/
- pd/doc/5.reference/<lib>/
- pd/doc/<lib>/
- pd/doc/<lib>/<blablablabl>/<blablabl>/
^ 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.
The Help Browser is just a file browser of pd/doc/. It doesn't read -
help-path. But the grand PDDP plan has this specified. Anyone want
to implement it?
i'd say this is not the way to go. it's handy to have an overview of all objects of a certain lib. also would it be nice to have the helppatches of the libs separated from pd's own helppatches.
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.
It would make sense to have the help patches sorted by lib if the
libs were actually coherent units, like in Java, C++, libc, etc. A
search functionality would be a better way to search for objects.
This is also spec'ed in the PDDP spec.
from the users point of view the following points would make life
easy:-all helppatches are named after <name>-help.pd, which makes browsing easier
Yes, definitely
- pd's own helppatches are located in pd/doc/5.reference (as it is
now)
Good.
- 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.
Or just add them to the helppath. That's all the libdir extension
does. I need to find some time to make the libdir stuff a proper
loader, using Thomas' loader functionality, then I'll submit it to
Miller.
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].
Actually, this is exactly what the libdir code does, and AFAIK, it
doesn't break things.
For my abstractions I like to keep it simple and I just place the help patches next to the original abstractions. This way I directly see which abstraction are still without help-patch. For "installing" these patches I think, the libdir approach makes the most sense.
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.
The current help browser was meant to be a temporary hack. Anyone
want to write the replacement?
.hc
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
I spent 33 years and four months in active military service and
during that period I spent most of my time as a high class muscle man
for Big Business, for Wall Street and the bankers. - General
Smedley Butler
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Aug 21, 2006, at 8:48 AM, Frank Barknecht wrote:
Roman Haefeli hat gesagt: // Roman Haefeli wrote:
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].
Actually, this is exactly what the libdir code does, and AFAIK, it doesn't break things.
Hm , I can't follow this: Are you saying, that pd-extended already searches pd/doc/5.reference recursively for help files? But if you have, for example, a directory "zexy" with "urn-help.pd" in it and also a directory "maxlib" with "urn-help.pd" in it, and also a toplevel "urn-help.pd", maybe coming from cyclone, how do you select the right help file when you try to open help for "urn"? Searching recursively will find all three and it circuments all directory prefixes.
The current help browser was meant to be a temporary hack. Anyone
want to write the replacement?
I don't know Tk enough. My criticism is just, that the previous file browser was the better temporary hack, because it offered several features, which now are temporarily disbled as well without gaining anything in turn, as far as I can judge.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Sep 1, 2006, at 7:40 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Aug 21, 2006, at 8:48 AM, Frank Barknecht wrote:
Roman Haefeli hat gesagt: // Roman Haefeli wrote:
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].
Actually, this is exactly what the libdir code does, and AFAIK, it doesn't break things.
Hm , I can't follow this: Are you saying, that pd-extended already searches pd/doc/5.reference recursively for help files? But if you have, for example, a directory "zexy" with "urn-help.pd" in it and also a directory "maxlib" with "urn-help.pd" in it, and also a toplevel "urn-help.pd", maybe coming from cyclone, how do you select the right help file when you try to open help for "urn"? Searching recursively will find all three and it circuments all directory prefixes.
Sorry, not recursively, I misunderstood. Its just that when you load
a libdir, it adds its path to the global help path.
The current help browser was meant to be a temporary hack. Anyone want to write the replacement?
I don't know Tk enough. My criticism is just, that the previous file browser was the better temporary hack, because it offered several features, which now are temporarily disbled as well without gaining anything in turn, as far as I can judge.
The previous browser was a better temporary hack on Linux, it was
very, very broken on Mac OS X, and limited on Windows. Feel free to
submit a patch to re-add the old one for Linux/Windows. It could
easily be included in Pd-extended.
.hc
I have the audacity to believe that peoples everywhere can have three
meals a day for their bodies, education and culture for their minds,
and dignity, equality and freedom for their spirits. - Martin
Luther King, Jr.
-
Frank Barknecht -
Hans-Christoph Steiner -
Kyle Klipowicz -
Roman Haefeli