kicad-developers team mailing list archive

[Rene Pöschl <poeschlr@xxxxxxxxx>]

Hi again,

A few clarification questions:

Would your proposed solution replace the way of defining footprints in 
the symbol file format of the future or would this be in parallel to it. 
(I lean towards the fact that it should replace it as i fear we 
otherwise end up with something similar to what we had with the 
datasheet being stored in either dcm or lib files. But i can also 
imagine that this would not be very well liked by the community) 
Similarly with footprint filters. In the official lib we use it for 
fully specified symbols to allow adding manufacturing specific 
variations. (Inclusion of thermal vias, hand soldering alternative, ...) 
How would that come into play?

Your system would take care of adding bom info via properties. Right now 
such fields can already be added to a symbol directly or via eeschema. 
Again something where we might want to either limit it to one place in 
the library or have clear rules which place takes precedence. (An 
interesting case is if there are different fields in the symbol compared 
to the new part specifier. Should the result be a union of both sets of 
properties or should only the part properties be used?)

On 23/05/19 21:41, Seth Hillbrand wrote:
> Hi All-
>
> After some discussion, we are trying to decide whether implementing a
> basic atomic library support would be useful during v6 or would cause
> more headache than worth while trying to work with the solution.
>
> Background: "Atomic" libraries are ones that have unique names for
> symbol+footprint+properties combinations.  These are also referred to as
> "Fully-specified" libraries or sometimes "house libraries".
>
> The paradigm is outlined in a google document[1].  This is meant to
> provide an explicit option for users to create/utilize atomic library
> components without affecting the symbol or footprint formats.  It is
> also meant to be zero impact to the current, official KiCad libraries.
>
> The major limitations of the specification are:
> - No editing of the atomic library file within KiCad
> - The atomic library does not contain symbol or footprint data
>
> Folks are welcomed to weigh in on whether this approach presents a
> viable work flow for them.  I'm happy to take suggestions on the
> approach, I may ask you offline for some additional details of how you
> use KiCad and/or other tools with libraries at the moment.
>
> Best-
> Seth
>
>
> [1]
> https://docs.google.com/document/d/1FNPmUAkNVt7r9oz32OznDrqL8RHdGHpO-eiBVEzHCOs/edit?usp=sharing
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp