Comment 11 for bug 575810

On Fri, 21 May 2010, Wayne Stambaugh wrote:

> On 5/20/2010 11:09 PM, Dick Hollenbeck wrote:
>> Wayne Stambaugh wrote:
>>> On 5/20/2010 2:36 PM, jean-pierre charras wrote:
>>>
>>>> Dick Hollenbeck a écrit :
>>>>
>
> <<< snipped >>>

Just my opinion given my experience and usage pattern:

Give the library a logical name (i.e. the lowercase filename without
extension) and a search path where to find them.

Libraries with the same name are not needed IMHO. A file rename could
easily fix the issue anyway.

Then define a search order between libraries (like a move up/down in the
library dialog) and use it for unqualified names.

So you could access to a *specific* object with its fully qualified name
("library.object" or "library/object", it's only a syntax issue). Or you use
only "object" for the *top* object in the search order.

That is:
1) Exactly like how paths in file systems work, so already clear for
a lot of people (iirc even word macros work this way)
2) Does not broke existing design (at least the sane ones:D)
3) Easy to implement
4) Give a good default (i.e. search order if you type it or fully
qualified for browser picked)
5) Allows some kind of 'technology level' choice (a somewhat extreme
example, on a dual mounted board you could have a "reflow.so8" and
a "wave.so8" for components on different sides... but nothing you
couldn't already do with careful naming conventions).
6) OTOH it could be useful for some global replace operations: I had to
switch a whole board from 6mil process to 8mil process; just changed the
loaded libraries and 'changed all' the modules; that would of course
work only for search order objects...

As from the differences between schematic symbols and pcb packages,
*these are different*: the schematic symbol is always took from
a library, and is isn't mean to be changed at the instance level; the
footprint is exactly the opposite, it could be a one-shot instance for
an exotic component or you could modify just a single instance... a few
days ago I reduced a single pad of an RCA connector to squeeze another
track between:P that doesn't mean that I want *every* RCA connector to
have that reduced pad (suggestion: make *locked* parts immune from
"change all" to keep this advantage).

I agree that eeschema cache has no reason to exist... if it's only to
make the schematic independant from libraries put the symbols in the
.sch itself. If you remove the cache capability then you need symbol
versioning to avoid breaking old schematics when you modify the
libraries... (anyway that's already happening since the cache seems to
be used as a last search resort, so the cache doesn't do anything useful
these days)

I'd propose to rip out the cache fully (like the library description
files, as proposed a while ago, have no reason to still exist since the
library is fully loaded in ram anyway)

--
Lorenzo Marcantonio
Logos Srl