Do there really need to be eight different font-related entries in the path list for Pd-extended on OS X? If so, why?
Phil
Well, it makes it easier to find fonts. That's the reason. I suppose
most people aren't using fonts much with Pd. If [declare -path] works
for Gem fonts, then I would consider removing some from the default
prefs.
.hc
On Mar 26, 2009, at 9:23 PM, Phil Stone wrote:
Do there really need to be eight different font-related entries in
the path list for Pd-extended on OS X? If so, why?Phil
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Computer science is no more related to the computer than astronomy is
related to the telescope. -Edsger Dykstra
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.
Thanks, Hans.
Phil
Hans-Christoph Steiner wrote:
Well, it makes it easier to find fonts. That's the reason. I suppose most people aren't using fonts much with Pd. If [declare -path] works for Gem fonts, then I would consider removing some from the default prefs.
.hc
On Mar 26, 2009, at 9:23 PM, Phil Stone wrote:
Do there really need to be eight different font-related entries in the path list for Pd-extended on OS X? If so, why?
Phil
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra
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
-
Hans-Christoph Steiner -
Mathieu Bouchard -
Phil Stone