Hello folks,
I have a proposed addition to CVS that I'm a little nervous about adding without consulting others first. I did a little cut-modify-and-paste of some existing functions, and I have a first pass on code that allows one to modify the help search path. It's not pretty or well-tested, but I hope some will agree that's what CVS is for...
The usage is pretty straightforward: -helppath <path> -- add to help file search path
It works in the same order that you might expect from the -path command- line option (since it is basically a simplified version of the same search function).
Some thoughts: 1) It's on Miller's to-do list in notes.txt. Might be a good thing to get to it now; might be a bad thing to do it the "wrong" way. 2) The code is definitely a hack. It's not even a good one. 3) I would *really* like this functionality to be in at least one version of Pd... IMHO, it would *really* help the usability, especially on MacOSX, so that there's a unified place for newbies to install externals from the Finder. (e.g., /Library/Pd/externals and /Library/Pd/help, which could be over-ridden by stuff in ~/Library/Pd )
I haven't checked anything in, yet, but the code is ready to go.
Cheers, adam
-- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Adam Lindsay +44(0)1524 594 537 atl@comp.lancs.ac.uk http://www.comp.lancs.ac.uk/computing/users/atl/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Having gone for a full 12 hours without feedback (and having slept on it), I checked in the below-mentioned changes to devel_0_36. It touches g_editor, s_main, s_path, and m_pd.h. Testing and feedback welcomed.
adam
Adam Lindsay said this at Thu, 20 Feb 2003 01:22:21 +0000:
Hello folks,
I have a proposed addition to CVS that I'm a little nervous about adding without consulting others first. I did a little cut-modify-and-paste of some existing functions, and I have a first pass on code that allows one to modify the help search path. It's not pretty or well-tested, but I hope some will agree that's what CVS is for...
The usage is pretty straightforward: -helppath <path> -- add to help file search path
It works in the same order that you might expect from the -path command- line option (since it is basically a simplified version of the same search function).
Some thoughts:
- It's on Miller's to-do list in notes.txt. Might be a good thing to get
to it now; might be a bad thing to do it the "wrong" way. 2) The code is definitely a hack. It's not even a good hack. 3) I would *really* like this functionality to be in at least one version of Pd... IMHO, it would *really* help the usability, especially on MacOSX, so that there's a unified place for newbies to install externals from the Finder. (e.g., /Library/Pd/externals and /Library/Pd/help, which could be over-ridden by stuff in ~/Library/Pd )
I haven't checked anything in, yet, but the code is ready to go.
Cheers, adam
--
Adam Lindsay +44(0)1524 594 537 atl@comp.lancs.ac.uk http://www.comp.lancs.ac.uk/computing/users/atl/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
Hallo, Adam Lindsay hat gesagt: // Adam Lindsay wrote:
Having gone for a full 12 hours without feedback (and having slept on it), I checked in the below-mentioned changes to devel_0_36. It touches g_editor, s_main, s_path, and m_pd.h. Testing and feedback welcomed.
I won't be able to test it until next tuesday or thursday.
(I have mixed feelings with changes to m_pd.h in general, though, because that's a "system header")
ciao
On Thu, 20 Feb 2003, Frank Barknecht wrote:
Adam Lindsay hat gesagt: // Adam Lindsay wrote:
Having gone for a full 12 hours without feedback (and having slept on it), I checked in the below-mentioned changes to devel_0_36. It touches g_editor, s_main, s_path, and m_pd.h. Testing and feedback welcomed.
I won't be able to test it until next tuesday or thursday.
(I have mixed feelings with changes to m_pd.h in general, though, because that's a "system header")
mhm, do we really need this in m_pd.h ? Having it there means that externals should be able to add a new helppath, and it will become part of the pd external interface. I think it does not need to be. If you need the declarations in different files within pd Either
1) Put it in m_imp.h 2) Put a declaration on top of the file where you use the function.
Sorry about my ignorance, but isn't the help path relative to the pd installation path ? Isn't the installation path the path that should be changeable during runtime (together with the default externals path "extra" and the bin directory) ?
I might be wrong, have to check before complaining actually ...
Greetings,
Guenter
Hi, Guenter, Frank, all,
guenter geiger said this at Thu, 20 Feb 2003 17:39:56 +0100:
I won't be able to test it until next tuesday or thursday.
(I have mixed feelings with changes to m_pd.h in general, though, because that's a "system header")
mhm, do we really need this in m_pd.h ?
You're both right, we don't. I was being very literal in my imitation of sys_addhelppath() and open_via_path(). I put the declarations where they should be, and did a commit.
If you need the declarations in different files within pd Either
- Put it in m_imp.h
- Put a declaration on top of the file where you use the function.
Thanks. That's an important coding guideline.
Sorry about my ignorance, but isn't the help path relative to the pd installation path ? Isn't the installation path the path that should be changeable during runtime (together with the default externals path "extra" and the bin directory) ?
The way I use the helppath namelist is to initialise it with the pd path + /doc/5.reference (so it works as normal).
If I want to, for example, add pddp help patches without overwriting the original pd help patches, I can put them in another directory, and then add that directory as another line in my .pdrc. I personally would use these -path and -helppath directives to keep the pd installation "clean" and then point to other directories for externals and their help patches.
I might be wrong, have to check before complaining actually ...
I'm not sure I understood your question. I hope I approached a little of the "why", though.
Thanks for keeping me honest, adam
Hallo, Adam Lindsay hat gesagt: // Adam Lindsay wrote:
If I want to, for example, add pddp help patches without overwriting the original pd help patches, I can put them in another directory, and then add that directory as another line in my .pdrc. I personally would use these -path and -helppath directives to keep the pd installation "clean" and then point to other directories for externals and their help patches.
I know of some externals, for example iemlib, that already put their help-files into subdirectories. iemlib for exampls looks in doc/5.reference/iemhelp/
In the source, this is achieved by setting the path relative to the default help path:
class_sethelpsymbol(t3_delay_class, gensym("iemhelp/help-t3_delay"));
I did this, too, once.
ciao
Frank Barknecht said this at Thu, 20 Feb 2003 18:58:25 +0100:
Hallo, Adam Lindsay hat gesagt: // Adam Lindsay wrote:
If I want to, for example, add pddp help patches without overwriting the original pd help patches, I can put them in another directory, and then add that directory as another line in my .pdrc. I personally would use these -path and -helppath directives to keep the pd installation "clean" and then point to other directories for externals and their help patches.
I know of some externals, for example iemlib, that already put their help-files into subdirectories. iemlib for exampls looks in doc/5.reference/iemhelp/
Yup. I'm aware of that. That puts control in the hands of the externals developer, and not the end-user, though. This way it will also look in my/help/dir/iemhelp before doc/5.reference/iemhelp.
/usr/local/pd/doc/5.reference is a fairly obscure directory for users to have to find (especially with the /usr tree generally hidden from the Mac GUI). I'm hoping to allow for easier installation of externals this way.
adam
On Thu, 20 Feb 2003, Adam Lindsay wrote:
- Put it in m_imp.h
- Put a declaration on top of the file where you use the function.
Thanks. That's an important coding guideline.
If you take it as a coding guideline, forget about option 2. Its a hack.
The way I use the helppath namelist is to initialise it with the pd path
- /doc/5.reference (so it works as normal).
If I want to, for example, add pddp help patches without overwriting the original pd help patches, I can put them in another directory, and then add that directory as another line in my .pdrc. I personally would use these -path and -helppath directives to keep the pd installation "clean" and then point to other directories for externals and their help patches.
I might be wrong, have to check before complaining actually ...
I'm not sure I understood your question. I hope I approached a little of the "why", though.
Yes, the "why" answers my question perfectly. Keeping the pd installation clean, makes a lot of sense, definitely. Especially on architecture where this issue is not handled by the installer.
Guenter
-
Adam Lindsay -
Frank Barknecht -
guenter geiger