Hey all,
As most of you know I'm very annoyed that I can only have one user-wide plist file. This is when I'm testing experimental versions of externals and such, I actually have to rename my plist so that PD does not load it. Ugly solution.
Anyhow I thought another way of fixing the problem of multiple configurations would be negative options when starting PD. Say I have an experimental Gem in ~/libs/ and a stable version in ~/libs/cgc. Assuming my plist (.pdrc) contains a path for the former then I would start PD with this in order to load the unstable version:
pd -without-path ~/libs -path ~/libs/cgc -lib Gem
So that we could turn on, and more importantly off, any options in the plist that we don't want for this run.
Anyhow just an idea.
Maybe there are not that many people out there with 4 different versions of libs on their machines? (For Gem I have: experimental, cgc, vertex array, multiple gem-window etc..)
Some kind of configuration manager would also do the job, as would the ability to switch to a global configuration (plist) file (pd -pdrc ~/mine.plist).
B.
This problem seems to mainly affect Pd developers, so I think we need to be careful about adding complexity that few people would use and many people might be confused by, especially when we can do it in a simpler way (like the quote says below :)
You could easily use a simple shell script to manage the .plist files, then it would make it easy to switch them. Something like this (this is off-the-cuff, so it might not work):
--------------------------------- #!/bin/sh
# location of plist that Pd reads PLIST_ROOT=~/Library/Preferences/org.puredata.pd PLIST=$PLIST_ROOT.plist
# which config to use (first argument) CONFIG=$1
cp -f "$PLIST_ROOT.$CONFIG.plist" "$PLIST" ---------------------------------
Then you'd choose the config you want by doing:
./config-switcher.sh experimental
or
./config-switcher.sh vertex
It would not be hard to expand the script to save new configs as well. (This is also a good candidate for the "scripts" section of CVS.)
.hc
On Mar 22, 2005, at 11:15 AM, B. Bogart wrote:
Hey all,
As most of you know I'm very annoyed that I can only have one user-wide plist file. This is when I'm testing experimental versions of externals and such, I actually have to rename my plist so that PD does not load it. Ugly solution.
Anyhow I thought another way of fixing the problem of multiple configurations would be negative options when starting PD. Say I have an experimental Gem in ~/libs/ and a stable version in ~/libs/cgc. Assuming my plist (.pdrc) contains a path for the former then I would start PD with this in order to load the unstable version:
pd -without-path ~/libs -path ~/libs/cgc -lib Gem
So that we could turn on, and more importantly off, any options in the plist that we don't want for this run.
Anyhow just an idea.
Maybe there are not that many people out there with 4 different versions of libs on their machines? (For Gem I have: experimental, cgc, vertex array, multiple gem-window etc..)
Some kind of configuration manager would also do the job, as would the ability to switch to a global configuration (plist) file (pd -pdrc ~/mine.plist).
B.
________________________________________________________________________ ____
"Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies."
- Amy Smith
OK!
This is a guess true that it is a developer problem (though I don't know if that is indeed what I am) user who needs a more complex system than the average?!
Say we have a tcl-script that looks for org.pure-data*.plist files in library/Preference and provides a faclity to selecting one of these files. On click a symbolic link is made and repoints org.pure-data.pd.plist to the appropriate plist file. (or .pdrc)
Would this be of use to anyone?
B.
Hans-Christoph Steiner wrote:
This problem seems to mainly affect Pd developers, so I think we need to be careful about adding complexity that few people would use and many people might be confused by, especially when we can do it in a simpler way (like the quote says below :)
You could easily use a simple shell script to manage the .plist files, then it would make it easy to switch them. Something like this (this is off-the-cuff, so it might not work):
#!/bin/sh
# location of plist that Pd reads PLIST_ROOT=~/Library/Preferences/org.puredata.pd PLIST=$PLIST_ROOT.plist
# which config to use (first argument) CONFIG=$1
cp -f "$PLIST_ROOT.$CONFIG.plist" "$PLIST"
Then you'd choose the config you want by doing:
./config-switcher.sh experimental
or
./config-switcher.sh vertex
It would not be hard to expand the script to save new configs as well. (This is also a good candidate for the "scripts" section of CVS.)
.hc
On Mar 22, 2005, at 11:15 AM, B. Bogart wrote:
Hey all,
As most of you know I'm very annoyed that I can only have one user-wide plist file. This is when I'm testing experimental versions of externals and such, I actually have to rename my plist so that PD does not load it. Ugly solution.
Anyhow I thought another way of fixing the problem of multiple configurations would be negative options when starting PD. Say I have an experimental Gem in ~/libs/ and a stable version in ~/libs/cgc. Assuming my plist (.pdrc) contains a path for the former then I would start PD with this in order to load the unstable version:
pd -without-path ~/libs -path ~/libs/cgc -lib Gem
So that we could turn on, and more importantly off, any options in the plist that we don't want for this run.
Anyhow just an idea.
Maybe there are not that many people out there with 4 different versions of libs on their machines? (For Gem I have: experimental, cgc, vertex array, multiple gem-window etc..)
Some kind of configuration manager would also do the job, as would the ability to switch to a global configuration (plist) file (pd -pdrc ~/mine.plist).
B.
"Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies."
- Amy Smith
-
B. Bogart -
Hans-Christoph Steiner