kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #03640
Re: Eeschema library editor - seperate value + name
-
To:
kicad-devel@xxxxxxxxxxxxxxx
-
From:
Brian Sidebotham <brian.sidebotham@...>
-
Date:
Fri, 13 Nov 2009 12:09:16 +0000
-
In-reply-to:
<4AFCB8A4.5030903@...>
2009/11/13 Wayne Stambaugh <stambaughw@...>:
> Brian,
>
> Thanks for the explanation of heavy versus light libraries. I wasn't
> getting this (I'm a little slow sometimes) from some of the previous
> posts. The weakness I see in this is if for any reason your had to
> change the base component symbols, you would have to update the entire
> library as opposed just changing the library root component. Also the
> libraries could become huge (potentially 10s of thousands of parts for
> resistor and capacitor libraries) which would significantly impact
> performance and memory use. You have also effectively made field 5 a
> part number field which may not work for everyone else. You solution
> sounds like it is better suited for creating user specific component
> information as opposed to a robust set of component libraries that would
> ship with Kicad. I understand what it is you are trying to accomplish.
Hi Wayne,
I failed to mention the fact that I would intend a true heavy symbol
implimentation to be accomplished with one component that is then
aliased. I didn't realise that the aliases are in the dcm file as
Jean-Pierre mentions in his next email. I'll reply to that and perhaps
I can get a workload together. Hopefully the changes will not need to
be too deep.
Field 5 is something I can use for whatever purpose as anyone can. I
am not proposing that KiCad itself move over to a heavy symbol library
or even be bundled with one, just that it provides the ability to have
one. I'm also not trying to suggest a new symbol library format per
sae; that is the subject of another discussion.
> I have the same problems when I create BOMs. I am just not sure that
> this is the best way to attack the problem. Maybe this is where some
> type of database implementation would be useful that some of the other
> developers have suggested. That way all your local information, part
> numbers, manufacturers, vendors, cost, etc. would be independent of the
> actual component libraries themselves. If you could separate it out
> that way or by some other method, it would probably be easier for other
> to accept.
There is a seperate discussion about the pro's and con's of different
types of implimentations for symbol libraries and it looks like people
have some great ideas and lots of opinions. I don't really want to
escalate to that arena. I feel that a little tickling of the code
could help initially support a heavy system with what KiCad has
available right now, probably with a few warts, but the ability to
support something is better than not.
Best Regards,
Brian.
References