On Thu, 26 Mar 2009, Phil Stone wrote:
Oh, Gem, of course. So when I'm not using Gem, I can safely do without those eight path elements, then? Also, while I'm being a whinging pest...it's impossible to add a path element that lives inside the pd-extended.app "folder" using the path dialog. This is because OS X makes the .app package not look like a folder, I suppose, but it's unfortunate nevertheless. Off to edit the .plist, I go.
If Pd-Extended is GPL'd, then it could use some code that I wrote some years ago (mid-2006?) for editing pdrc:
http://artengine.ca/desiredata/gallery/pdrc_6.png
Except that it would be made to work with Pd's path system instead of reading/writing .pd files.
If that part of Pd-Extended is not GPL'd, this is a tiny piece of quite ordinary code really, so, much any adaptation of it will look like it was made by someone else... copyright applies better on bigger or more original chunks of code.
So, the "add" button opens a folder-selection dialogue box for adding a path at the bottom of the list. The "remove" button removes the currently selected row in the listbox. "up" and "down" move the currently selected entry up or down in the list, swapping position with the entry in that direction (to change path priorities). There is no known limit to the number of entries in that listbox. The 2nd listbox could be done away with if Pd-extended doesn't want a dialogue for -helppath. The rest of the dialogue can be ignored, you can do it the way you want.
(the example in the screenshot is obsolete... loading that lib now automatically modifies the -path and -helppath in an implicit way)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec