Re: gEDA: Symbol inheritance test

[James Cotton]

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 <[EMAIL PROTECTED]> 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:                       [EMAIL PROTECTED]
>> Other mail:                             [EMAIL PROTECTED]
>>
>
>