With this release of Pd-extended, all platforms have default
locations for user-installed externals, helpfiles, etc. I just had a
thought, perhaps ~/.pd would be a better directory than ~/pd. Any
thoughts on that?
Here's how it is now:
GNU/Linux: /usr/share/pd and ~/pd Mac OS X: /Library/Pd and ~/Library/Pd Windows: %ProgramFiles%/Common Files/Pd and %UserProfile%/ Application Data/Pd
.hc
¡El pueblo unido jamás será vencido!
An "official" folder would be ok. But it should be possible to reassign
this variable if necessary. In my case I have the work folder /jmmmp-ext
in the extras folder (where is also a jmmmp folder from pd). That allows
me to get to my work much faster than having something on my system user
folder.
When I update pd, it always overwrites everything but this folder,
evidently.
João
With this release of Pd-extended, all platforms have default locations for user-installed externals, helpfiles, etc. I just had a thought, perhaps ~/.pd would be a better directory than ~/pd. Any thoughts on that?
Here's how it is now:
GNU/Linux: /usr/share/pd and ~/pd Mac OS X: /Library/Pd and ~/Library/Pd Windows: %ProgramFiles%/Common Files/Pd and %UserProfile%/ Application Data/Pd
.hc
¡El pueblo unido jamás será vencido!
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
i think /Library/Application\ Support/Pure\ Data and ~/Library/Application\ Support/Pure\ Data would make more sense on OS X
m.
Am 2008-06-16 um 19:49 schrieb Hans-Christoph Steiner:
With this release of Pd-extended, all platforms have default locations for user-installed externals, helpfiles, etc. I just had a thought, perhaps ~/.pd would be a better directory than ~/pd. Any thoughts on that?
Here's how it is now:
GNU/Linux: /usr/share/pd and ~/pd Mac OS X: /Library/Pd and ~/Library/Pd Windows: %ProgramFiles%/Common Files/Pd and %UserProfile%/ Application Data/Pd
.hc
--
¡El pueblo unido jamás será vencido!
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Hans-Christoph Steiner wrote:
With this release of Pd-extended, all platforms have default
locations for user-installed externals, helpfiles, etc. I just had a
thought, perhaps ~/.pd would be a better directory than ~/pd. Any
thoughts on that?
Is there an advantage to making it invisible on top of being so well hidden that pd itself can't find it most of the time :?(
Martin
Hallo, Martin Peach hat gesagt: // Martin Peach wrote:
Hans-Christoph Steiner wrote:
With this release of Pd-extended, all platforms have default
locations for user-installed externals, helpfiles, etc. I just had a
thought, perhaps ~/.pd would be a better directory than ~/pd. Any
thoughts on that?Is there an advantage to making it invisible on top of being so well hidden that pd itself can't find it most of the time :?(
No. ;)
Dotfiles on unix generally are used for configuration only, not for documents. E.g. a mail software like Mutt has its config files in ~/.mutt/ but mails in ~/Mail/ or so. Same for ~/.openoffice etc.
So offering a ~/.pd for documents doesn't make much sense.
Ciao
Frank Barknecht _ ______footils.org__
Hans-Christoph Steiner wrote:
With this release of Pd-extended, all platforms have default
locations for user-installed externals, helpfiles, etc. I just had a
thought, perhaps ~/.pd would be a better directory than ~/pd. Any
thoughts on that?
i would rather have the configuration file(s) move into ~/.pd/ this way it is easy to add conffiles for other Pd-related stuff without cluttering the ~ even more.
Here's how it is now:
GNU/Linux: /usr/share/pd and ~/pd
ouch! according to the Filesystem Hierarchy Standard (http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENT...), this directory is reserved for "Architecture-independent data". traditional ("C") externals do not exactly fall into this category.
fgmard IOhannes
On Jun 16, 2008, at 3:46 PM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
With this release of Pd-extended, all platforms have default
locations for user-installed externals, helpfiles, etc. I just
had a thought, perhaps ~/.pd would be a better directory than ~/ pd. Any thoughts on that?i would rather have the configuration file(s) move into ~/.pd/ this way it is easy to add conffiles for other Pd-related stuff
without cluttering the ~ even more.Here's how it is now: GNU/Linux: /usr/share/pd and ~/pd
ouch! according to the Filesystem Hierarchy Standard (http:// www.pathname.com/fhs/pub/ fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA), this directory
is reserved for "Architecture-independent data". traditional ("C") externals do not exactly fall into this category.
Any suggestions for a better location? I know /usr/share/pd is not
ideal, but I couldn't think of anything better.
.hc
fgmard IOhannes
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
Hans-Christoph Steiner wrote:
On Jun 16, 2008, at 3:46 PM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
With this release of Pd-extended, all platforms have default
locations for user-installed externals, helpfiles, etc. I just had a thought, perhaps ~/.pd would be a better directory than ~/pd.
Any thoughts on that?i would rather have the configuration file(s) move into ~/.pd/ this way it is easy to add conffiles for other Pd-related stuff without cluttering the ~ even more.
Here's how it is now: GNU/Linux: /usr/share/pd and ~/pd
ouch! according to the Filesystem Hierarchy Standard (http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENT...), this directory is reserved for "Architecture-independent data". traditional ("C") externals do not exactly fall into this category.
Any suggestions for a better location? I know /usr/share/pd is not ideal, but I couldn't think of anything better.
hmm, what is wrong with /usr/lib/pd ? neither /usr/share nor /usr/lib nor the entire /usr are free for the _user_ (despite the name); /usr contains "shareable, read-only data" (FHS); this is usually interpreted as being under the sole control of the package-manager (if such a thing exists), and is in any case _system wide_.
so, it would be ok if abstractions, python-externals and other platform-independent objects would go into /usr/share/pd whereas compiled (that is: platform dependent) objects (aka: C-externals) must go into /usr/lib/pd
for the sake of simplicity i would say it doesn't make so much sense, i would therefore suggest to just stay with /usr/lib/pd (it would make sense if Pd-extended was split into several packages, some of them being plaftorm-dependent (containing binaries) and other platform-independent)
fmgasd,.r IOhannes
On Jun 17, 2008, at 8:36 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
On Jun 16, 2008, at 3:46 PM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
With this release of Pd-extended, all platforms have default
locations for user-installed externals, helpfiles, etc. I just
had a thought, perhaps ~/.pd would be a better directory than ~/ pd. Any thoughts on that?i would rather have the configuration file(s) move into ~/.pd/ this way it is easy to add conffiles for other Pd-related stuff
without cluttering the ~ even more.Here's how it is now: GNU/Linux: /usr/share/pd and ~/pd
ouch! according to the Filesystem Hierarchy Standard (http:// www.pathname.com/fhs/pub/ fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA), this directory
is reserved for "Architecture-independent data". traditional ("C") externals do not exactly fall into this category.Any suggestions for a better location? I know /usr/share/pd is
not ideal, but I couldn't think of anything better.hmm, what is wrong with /usr/lib/pd ? neither /usr/share nor /usr/lib nor the entire /usr are free for
the _user_ (despite the name); /usr contains "shareable, read-only
data" (FHS); this is usually interpreted as being under the sole
control of the package-manager (if such a thing exists), and is in
any case _system wide_.so, it would be ok if abstractions, python-externals and other
platform-independent objects would go into /usr/share/pd whereas
compiled (that is: platform dependent) objects (aka: C-externals)
must go into /usr/lib/pdfor the sake of simplicity i would say it doesn't make so much
sense, i would therefore suggest to just stay with /usr/lib/pd (it
would make sense if Pd-extended was split into several packages,
some of them being plaftorm-dependent (containing binaries) and
other platform-independent)fmgasd,.r IOhannes
In Debian, and probably other distros, /usr/lib is not for user-
modified/user-added files, that's the problem with /usr/lib/pd. So
if we are going to follow the /usr/share policy, then we should
follow related policies as well.
Then if it uses /usr/local/lib/pd, that would conflict with user- installed Pd versions.
.hc
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
Hans-Christoph Steiner wrote:
On Jun 17, 2008, at 8:36 AM, IOhannes m zmoelnig wrote:
In Debian, and probably other distros, /usr/lib is not for user- modified/user-added files, that's the problem with /usr/lib/pd. So
if we are going to follow the /usr/share policy, then we should
follow related policies as well.
this is what i am trying to say.
/usr/lib is NOT for user-modified/user-added files AND /usr/share is NOT for user-modified/user-added files
no-one (but the package-maintainers), esp. not a "user", must but anything into /usr (with the noteable exception of /usr/local)
Then if it uses /usr/local/lib/pd, that would conflict with user- installed Pd versions.
so how about /usr/local/lib/pd-extended ? (see the other email)
mfg.asd IOhannes
No. Hidden home directory files traditionally have a special meaning. They are initialisation resources.
~/.something is a place a program will go to look for startup options (in a particular order after /var/something ... so that global and multi user configs can live together)
I know some recent Linux apps have started putting userworld resources into dot directories, but this is bad practice imho.
2c
andy.
On Mon, 16 Jun 2008 11:49:53 +0200 Hans-Christoph Steiner hans@eds.org wrote:
With this release of Pd-extended, all platforms have default
locations for user-installed externals, helpfiles, etc. I just had a
thought, perhaps ~/.pd would be a better directory than ~/pd. Any
thoughts on that?Here's how it is now:
GNU/Linux: /usr/share/pd and ~/pd Mac OS X: /Library/Pd and ~/Library/Pd Windows: %ProgramFiles%/Common Files/Pd and %UserProfile%/ Application Data/Pd
.hc
¡El pueblo unido jamás será vencido!
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hans, While I don't really have any feelings about this external directory, it would be nice to have a different properties file from what Vanilla Pd uses, this way we can have two different setups, and they won't interfere with each other. Currently, I have one properties file that both versions of Pd appear to be trying to load, but because the properties file was built for Pd-extended, loading Vanilla Pd generates errors for everything that it tries to load, as it can't find those things.
Mike
On Mon, Jun 16, 2008 at 4:49 AM, Hans-Christoph Steiner hans@eds.org wrote:
With this release of Pd-extended, all platforms have default locations for user-installed externals, helpfiles, etc. I just had a thought, perhaps ~/.pd would be a better directory than ~/pd. Any thoughts on that?
Here's how it is now:
GNU/Linux: /usr/share/pd and ~/pd Mac OS X: /Library/Pd and ~/Library/Pd Windows: %ProgramFiles%/Common Files/Pd and %UserProfile%/ Application Data/Pd
.hc
¡El pueblo unido jamás será vencido!
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Mike McGonagle wrote:
Hans,
While I don't really have any feelings about this external directory, it would be nice to have a different properties file from what Vanilla Pd uses, this way we can have two different setups, and they won't interfere with each other.
i very much like this. for the linux-packages, i therefore would also ask to:
- install into /usr/lib/pd-extended/ rather than /usr/lib/pd/
- startup as /usr/bin/pd-extended rather than /usr/bin/pd
- use a different settings file (e.g. ~/.pd/pd-extended.settings)
- remove the package-conflict between pure-data and pd-extended
for the user who prefers to start Pd via the menu, this will not change much.
for the user who prefers running Pd from the console (or scripts) this will eventually require a change, which could be alleviated by using "alternatives" (man update-alternatives)
fgnmasdr IOhannes
On Jun 17, 2008, at 8:44 AM, IOhannes m zmoelnig wrote:
Mike McGonagle wrote:
Hans, While I don't really have any feelings about this external
directory, it would be nice to have a different properties file
from what Vanilla Pd uses, this way we can have two different
setups, and they won't interfere with each other.i very much like this. for the linux-packages, i therefore would also ask to:
- install into /usr/lib/pd-extended/ rather than /usr/lib/pd/
- startup as /usr/bin/pd-extended rather than /usr/bin/pd
- use a different settings file (e.g. ~/.pd/pd-extended.settings)
- remove the package-conflict between pure-data and pd-extended
for the user who prefers to start Pd via the menu, this will not
change much.for the user who prefers running Pd from the console (or scripts)
this will eventually require a change, which could be alleviated by
using "alternatives" (man update-alternatives)
This is a separate issue. I am talking about a common directory for
user-installed files. Windows and Mac OS X have pretty clear folders
for this. It gets muddy on GNU/Linux if we want the Pd-extended
packages not to conflict with user-installed Pd versions, otherwise
it should be /usr/local/lib/pd. Or perhaps it should be:
~/pd-externals/ /usr/local/lib/pd-externals/
.hc
fgnmasdr IOhannes
Access to computers should be unlimited and total. - the hacker ethic
Hans-Christoph Steiner wrote:
On Jun 17, 2008, at 8:44 AM, IOhannes m zmoelnig wrote:
i very much like this. for the linux-packages, i therefore would also ask to:
- install into /usr/lib/pd-extended/ rather than /usr/lib/pd/
- startup as /usr/bin/pd-extended rather than /usr/bin/pd
- use a different settings file (e.g. ~/.pd/pd-extended.settings)
- remove the package-conflict between pure-data and pd-extended
for the user who prefers to start Pd via the menu, this will not change much.
for the user who prefers running Pd from the console (or scripts) this will eventually require a change, which could be alleviated by using "alternatives" (man update-alternatives)
This is a separate issue.
i know that it is. i thought i'd just chime into mike's idea because i like it.
fmasdr IOhannes
Hans-Christoph Steiner wrote:
user-installed files. Windows and Mac OS X have pretty clear folders for this. It gets muddy on GNU/Linux if we want the Pd-extended packages not to conflict with user-installed Pd versions, otherwise it should be /usr/local/lib/pd. Or perhaps it should be:
~/pd-externals/ /usr/local/lib/pd-externals/
is there any special need for both having the same name?
furthermore, just to clarify: if the user wants to install addon packages for pd-extended, these should of course install into /usr/lib/pd
let's have a look how other apps handle this. e.g. mozilla/firefox uses (to my knowledge):
- /usr/lib/mozilla/plugins/ for system-wide plugins
- ~/.mozilla/plugins
so probably the original idea of using ~/.pd wasn't that bad, though i would recommend another directory level, e.g. ~/.pd/extra/
as you can see in mozilla, i am not entirely sure why one would need a standardized path where users can install non-packaged externals system-wide. it would be interesting to see, how many people currently are in need for such a thing.
finally, i find it more interesting to have a system-wide pdsettings (e.g. /etc/pd/pdsettings) which could be read either on top of (additional to) the ~/.pdsettings or be included from there.
oh, and (even more unrelated) it would probably be a good idea to split different configuration "sections" into different conffiles. e.g. ~/.pd/libraries.settings (for -path and -lib) ~/.pd/audio.settings ~/.pd/misc.settings this way one could have the audio.settings system-wide in /etc/pd/ and the library settings per-user in ~/.pd/library.settings and you would not be overwrite the audio-settings each time you save the path-settings.
mfgsdar IOhannes
Since this is about user installed externals, why not let each user
choose what colour they want their bike shed?
On Jun 17, 2008, at 3:57 PM, Steffen Juul wrote:
Since this is about user installed externals, why not let each user
choose what colour they want their bike shed?
For the same reason that "/usr/share" has a clearly defined purpose.
I am not going to prevent people from doing whatever they want, but
it helps a lot to have one clearly defined standard way of doing it.
I think I am going to go with /usr/local/lib/pd-externals and ~/pd-
externals. Then people can also map their vanilla, desiredata,
whatever installs to use this location as a common place to install
externals, if they so desire.
.hc
'You people have such restrictive dress for women,’ she said,
hobbling away in three inch heels and panty hose to finish out
another pink-collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
On Jun 17, 2008, at 6:05 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I think I am going to go with /usr/local/lib/pd-externals and ~/pd- externals.
What about abstractions?
True... got any suggestions for a better name? "externals" is such a
vague term anyway. This folder is intended for any kind of
objectclass, binary or ASCII, as well as helpfiles.
.hc
Ciao
Frank Barknecht _
______footils.org__
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
All information should be free. - the hacker ethic
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Jun 17, 2008, at 6:05 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I think I am going to go with /usr/local/lib/pd-externals and ~/pd- externals.
What about abstractions?
True... got any suggestions for a better name? "externals" is such a
vague term anyway. This folder is intended for any kind of
objectclass, binary or ASCII, as well as helpfiles.
Am I understanding it correctly, that these are just a paths pd-extended will include to the defaults in its settings? Then I'd use /usr/local/lib/pd/extra and for home maybe ~/pd/extra or just ~/pd.
The home path isn't important anyway as every user probably has her own file layout for home. And I don't think that every home should be standardized, I like it if all my friends' homes look different.
Ciao
Frank Barknecht _ ______footils.org__
Frank Barknecht wrote:
The home path isn't important anyway as every user probably has her own file layout for home. And I don't think that every home should be standardized, I like it if all my friends' homes look different.
standardized homes are beautiful as you can always feel at home... i would use "My Pd Extras"
fgmasdr IOhannes
On Jun 18, 2008, at 8:31 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Jun 17, 2008, at 6:05 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I think I am going to go with /usr/local/lib/pd-externals and ~/pd- externals.
What about abstractions?
True... got any suggestions for a better name? "externals" is such a vague term anyway. This folder is intended for any kind of objectclass, binary or ASCII, as well as helpfiles.
Am I understanding it correctly, that these are just a paths pd-extended will include to the defaults in its settings? Then I'd use /usr/local/lib/pd/extra and for home maybe ~/pd/extra or just ~/pd.
Yes.
The home path isn't important anyway as every user probably has her own file layout for home. And I don't think that every home should be standardized, I like it if all my friends' homes look different.
I'd rather not be mislead by metaphors. This is software, if the
software package sets up the environment for us, then we all have to
do less work to get things running. Personally, I'd rather make art
than manage a million different home directory configurations, and
all the problems that arise from that.
.hc
Ciao
Frank Barknecht _
______footils.org__
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
-
Andy Farnell -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
João Pais -
Martin Peach -
Max Neupert -
Mike McGonagle -
Steffen Juul