Re: gEDA: Symbol inheritance test

[James Cotton <peabody124@xxxxxxxxx>]

So for something like passives where there near limitless permutations
of footprints and values it doesn't seem productive to try and create a
set library.  It might be more beneficial to have a script that
takes a list of component values and footprints and then just copies
the base symbol and adds the relevant attributes.  This would
avoid the issue of inheritance in that it would create a copy of the
base.  If it used a sensible nomeclature, the output this could
then go into a local project related symbols directory.  That way
for your project with ten parts you would only have to scroll through
that list instead of searching through tons.  

This would also go along well with a searchable online database of
random heavy symbols.  Just grab the relevant ones and throw it in
the same folder instead of trying to maintain a local library of all
the available parts people have made.

James

On 12/11/05, Jonathan Hanson <hanson@xxxxxxxxxxxxxxxxxxx> wrote:

I don't know that we have to build a complete 'heavy' library at first.
As long as a strong tradition of submiting custom symbols when you make
them for your projects exists, the heavy library will grow on its own.
I personally had only planned to do a heavy set for basic passive
devices (capacitors and resistors) and then a few odds and ends like a
handful of transistor models and some diodes.  That covers most of what
I'll be using it for, and when I need some IC stuff later, I'll just
create the models as I go.
- Jonathan Hanson

Richard G. Munden wrote:

> The problem is solvable but it requires a change to the library
> architecture - a subject that has been discussed several times in the
> past.
>
> Rick Munden
>
>
> John Doty wrote:
>
>>> I think the symbol inheritance should work and could be a great
>>> addition, and the heavy libraries built could be configured in the
>>> search path library, so both light and heavy symbols guys will be
>>> happy.
>>
>>
>>
>> I don't think it's possible to satisfy the heavy symbols advocates. It
>> would require many millions of symbols to cover every component on the
>> market. As far as I'm concerned, the only sensible thing is to build
>> up a
>> library of custom symbols representing the parts stock you are going to
>> use for the design.
>>
>> I could wish that symbol directories specified in ./gafrc show up before
>> the standard libraries in the menu.
>>
>> John Doty          "You can't confuse me, that's my job."
>> MIT-related mail:                       jpd@xxxxxxxxxxxxx
>> Other mail:                             jpd@xxxxxxxxxxxxx
>>
>
>