Hi Ales -- [. . . . snip . . . .]
> >I also refactored code in all the programs which rely upon these > >functions in libgeda. > > This is probably a good idea, however, I never intended the user > to read in multiple different project gafrcs while running a single > instance of gschem, so I worry about the following related scenarios: > > 1) Picture that you have multiple schematics in muliple directories > (different projects or different revisions of the same schematic) > and you start opening them up and the local gafrc files get read in. > What happens if the gafrc themselves set component-library paths which > break the schematic? Is this a problem? Reading in two files works this way: 1. set the directory to that holding the new file A. 2. read in the local gafrc. 3. read in the schemtic A.sch. 4. set the directory to B's directory 5. read in the local gafrc 6. read in B.sch. Now, if you have the same symbol name in both A's and B's local lib, then B will be instantiated using A's symbol (or vice versa, depending upon search order). This might cause breakage, but it is a normal, everyday problem. The alternative is worse, IMHO: A newbie tries out gEDA, reads A.sch successfully, but browses over to B, tries to read it in, but finds it broken. The newbie can't figure out why B is broken, so he abandons gEDA altogether. > Another way to state the above: > > 2) Unless I have forgotten, but reading in a gafrc affects every > loaded schematic, so schematic A has its gafrc loaded (with its own > component-libraries), then the user loads schematic B and has its gafrc > loaded. Now the running gschem has two sets of component-libraries > which might clash. Again, do we care about this problem? It is a possibility, but is a normal issue with any piece of software which searches libraries to place parts or symbols. The power user learns to keep symbols named uniqely if he has many different local libraries. Also, note that in your scenario, schematic A has already been loaded and displayed, so nothing happens to A. Schematic B might have a part read out of A's library if you have identically-named parts in both libs. If you have identically-named symbols which show different graphics, then the problem lies with you, and not the program. FWIW: I have tested the changes on my machine where I have several schematics with different local libs, but the local libs have many identically-named components. I have seen no breakage; the identically named parts are identical; I have just copied them from one directory to another. I also name the local symbol library "./sym" in several directories. In testing, gschem happily reads both in, and displays both in the symbol browser. It is kind of stupid to have two directories called "sym" right next to each other, but that is my stupidity, not gschem's! :-) > Probably for the casual user, this change won't be too much of a problem, > however I worry about the experienced user . . . . The experienced user will see no change if he continues to use gEDA/gaf as in the past (i.e. sit in directory A and work on a.sch). If he browses over to directory B and opens up B.sch, then the libs on B's search path will appear in his sym lib browser & he will be able to use them on either A or B. Of course, if he places a component from B's lib on schematic A, then closes out & later re-opens A only, the B component won't be there. I expect the power user will know enough about how libraries work to avoid this problem. > . . . . . . . .who does something and all > of the sudden gschem thinks it's being smart and does something really > stupid or rather unexpected. I'm probably just being paranoid... As I always tell the folks in the marketing group at work [1]: That's why we do extensive testing before releasing the product on cutomers! Stuart [1] When they want to send a barely-hacked-together, engineering alpha-prototype product to customers, and are mad that testing places us "behind schedule".
