On Wed, Jan 13, 2016 at 11:06 AM, Wayne Stambaugh <[email protected]> wrote:
> On 1/12/2016 5:02 PM, Bernhard Stegmaier wrote: > > Hi, > > > > > >> On 12 Jan 2016, at 22:20, Cirilo Bernardo <[email protected] > >> <mailto:[email protected]>> wrote: > >> > >> Having a single reference point is extremely inflexible - how do you > >> handle user models? If a > >> package manager installs the files and you add to the directories then > >> your changes can be > >> overwritten later. If the directories are read-only then the user > >> can't add models. Some people > >> use ${KIPRJMOD} or other environment vars in the model names to work > >> around the current > >> limitations. Even if we had a scheme like fp-lib-table different users > >> will have to create > >> corresponding nicknames on different installations. > > > > Is it really? > > > > I didn’t exactly follow what you plan, but looking at fp-lib-table: > > Every user has his own fp-lib-table… either referencing the system > > libraries, maybe github libraries, or his own custom ones. > > A user can pick system-libraries he wants from system path and his own > > ones from some location he has write access and the system package > > manager won’t overwrite (his home folder I guess). > > How libraries are referenced in fp-lib-table is pretty much on behalf of > > the user. > > He can use pure absolute paths or some other base referenced via some > > environment variable (don’t know at the moment if it is limited to using > > ${KISYSMOD} or you can use an env variable that is defined). > > Using such a variable I can customise my various installations by just > > setting the local variable to the right path where my (local/private) > > models are. > > > > So, for me this looks quite flexible? > > At least, it allows me to open *my* projects on different machines I > > work on with the same (my) library but maybe different filesystem layout. > > > > My point is not about exchanging projects between different users on > > different machines. > > Of course, if I open a (foreign) project which references 3d-models > > other than those I have, they won’t be found. > > But I don’t see any reason why this should be better when using relative > > paths… > > When exchanging projects, as you said… either projects have to be > > completely self-contained or all parties have to use the same libraries > > (or, model directory structure). > > > > > > Regards, > > Bernhard > > Bernhard has described perfectly described why fp-lib-table is far > superior to any path list look up table irregardless if the path is > absolute, relative, and/or expanded from an environment variable. This > is exactly why it is designed this way. I have three different > platforms that have the same library nicknames appropriately configure > for each platform. The footprints in my projects are completely > portable between platforms. The same cannot be said of my 3D models > unless I define $KISYS3DMOD. The other problem with using paths is you > have now limited yourself to files on your system. I can think of a lot > other places that 3D model byte streams might come from besides a file > residing on my system. Using paths and files is very limited. > > I'm really confused now because (a) each user has to set the appropriate nickname/path to use another person's project file anyway, (b) there is no assurance that different users haven't chosen a particular nickname -say 'mypath1'- to point to different base paths, in which case someone has to make changes to a project file received from someone else anyway, and (c) fp-lib-table allows the liberal use of env vars anyway so that doesn't get us away from env vars either. In short: it's not clear to me (a) what issues people are thinking they want resolved and (b) how any of the proposed solutions address the issues. No matter what solution we settle on it will always be trivial to come up with a case which will cause the scheme to fail, so I favor the following priorities: (A) ease of the user to configure/use 3D models on their system, (B) ease of collaborating on a particular project within an organization, (C) sharing projects between random people. A scheme similar to fp-lib-table may be helpful but I would not use the fp-lib-table scheme as such, primarily because that uses one entry per directory and the user will quickly be swamped by a gazillion 3D paths to choose from. A brief description of the current situation: 3D models may have an absolute path, a path relative to the current dir (using "../"), a path relative to KISYS3DMOD, or a path relative to a random env var in cases where users have edited a footprint and associated a 3D model using an expression like ${MYPATH}/a_subdir/model.wrl So we would like to ensure that the legacy behavior works correctly - this is already accomplished in my branch except for the case which NickOE mentioned where 2 different paths may have different base paths but the same relative path. Now additional issues come up because we more or less universally agree that the legacy behavior is broken and must be changed. The questions we must answer are (a) what are these issues and (b) how can we address them? Looking back at the priorities (A), (B), (C), I believe (A), and (B) can be mostly resolved by using a system similar to fp-lib-table except that the entries specify a base path rather than a full path of a directory containing models. So for example: "mypath1", "/home/user/kicadlibs/3dpackages", "KiCad official 3D models" "mypath2", "/home/user/others/3dpackages", "My random models" let's say both of those paths happen to have a 'foo/bar.wrl' - this will now be represented in the pcb file as [^mypath1^]/foo/bar.wrl and [^mypath2^]/foo/bar.wrl So now the file can be uniquely resolved for a specific user under the assumption that the user doesn't change the values of mypath* to point to different model sets and then revisit an old project. Only a single base path is needed to represent each model dir tree; you are guaranteed of course that paths relative to that base are unique. Using a base path to a model dir tree of course allows us relatively easy access to many thousands of models without creating dozens of base path entries as would be required if we used a scheme exactly like fp-lib-table For (B), the collaborators can agree on policies etc to ensure that there are no problems. This is a matter beyond the scope of kicad software. For (C) possible solutions include (1) the various users must coordinate (sure), (2) we provide some function within kicad which ensures a local copy of all data required and changes internal data to use that local copy, and (3) because of the work involved with (2) treat this as Not Our Problem and simply let users employ (1) until such a time as we're inspired to provide a more convenient option. Of course it's trivial to imagine ways in which this scheme can fail but it is more robust than the existing scheme and addresses the various ways in which 3D model names are currently resolved while providing a more convenient interface for users and putting us on the path to discouraging the use of ${ENV_VAR} in the model names. Of course we *can* do: "mypath3", "${ENVVAR}", "My random envvar dir" and this should work, but such use should be discouraged. As for relative dirs and absolute paths (no known base path), what do we do? If we are to support legacy files we must support relative and absolute dirs although this breaks the aim of (A), (B), and (C). Alternatively we can refuse to support that aspect of legacy behavior and instead bring up a big warning (once only - not once per model) informing the user that they need to add a suitable entry to the base path search table. - Cirilo > > > > > > > > _______________________________________________ > > Mailing list: https://launchpad.net/~kicad-developers > > Post to : [email protected] > > Unsubscribe : https://launchpad.net/~kicad-developers > > More help : https://help.launchpad.net/ListHelp > > > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
