On Dec 17, 2004, at 3:01 AM, zmoelnig@iem.at wrote:
Zitiere Hans-Christoph Steiner hans@eds.org:
I'd like to propose an idea for organizing all of the objects, instead of placing everything directly in "extra" and "doc/5.reference". Everything that is aimed to be a standard part of Pd would go in "extra" and "5.reference". Then objects that have conflicted names, objects that are deprecated, or cyclone/Max-compatibility objects would go into their own folders. When someone wants to use these objects, they can add then directories using -path and -helppath.
correct me if i am wrong:
- let's assume wwe have a libraray "foo", containing of foo.pd_linux
and a number of help patches foo-help.pd and bar-help.pd; _now_ these files are in /usr/lib/pd/extra/: /usr/lib/pd/extra/foo.pd_linux, /usr/lib/pd/extra/foo-help.pd and /usr/lib/pd/extra/bar-help.pd you _propoese_ them to be in /usr/lib/pd/foo/ or in /usr/lib/pd/extra/foo ??
- the first solution would impose a bad thing on the usability of pd
(in my opinion): up till now, you can specify the libraries you want to be loaded in the patch itself, without having to hazzle with command-line arguments or rc-files: this is ok if you have only one evironment you work with, but if you want "several different pds-flavours" (libraries loaded,...) you would need to eliminate (or strip down) you rc-file and write quite long .BAT-fies (notice that the use of .BAT is on pupose as i really think this is old, clumsy and should be deprecated, especially with respect to the new console-less pd)
- the second solution is already implemented in pd (i think), so
people would just need to use it (which thy should do anyhow and which makes your proposal not at all "useless")
- problems with libraries containing mulitple so-files and pd-files
are a bit more complicated (so i guess you are refereing to that) i really think that the solution with giving a lot of path-names is _not_ good, because (as mentioned before) we are not (yet ?) able to add things to the search-path from within the patch (probably we are, with some weird messages) but anyhow, then we would need knowledge about the directory-layout on the harddisc which is a bad thing too) BUT: using your layout (without adding -path !) would enforce people to use our all-time favourite "namespaces" which is indeed a good thing.
so as a conclusion: i think too that libraries should go into separate directories, AND i think that these directories should be in pd/extra
I am not thinking at all about libraries because I think that externals should be distributed as individual objects, and I plan on making that happen in the distros that I work on. As far as I know, the only advantage that libraries currently have is shared code. I am going to try my hand at implementing Günter's idea of having a shared library for the shared code, while the objects are in individual files. Thomas Grill was working on this for flext also, I think he got it working.
One thing that I forgot to mention (which you did mention) is that you could also use the namespace to access these objects without adding anything to the path. For example, to use a deprecated object you would do this:
[deprecated/linuxjoystick /dev/input/event2]
So putting "../extra/deprecated" in the path would only be for porting the patch. Though this is much less necessary now that 0.38 will maintain the connections when an object can't be found.
.hc
________________________________________________________________________ ____
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams