kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 09/24/2010 03:41 AM, Lorenzo Marcantonio wrote:
> On Fri, 24 Sep 2010, Martijn Kuipers wrote:
>
>   
>> I would be very happy with an export function, doing: Export all used components into a project library.
>> This way I can send the schematics on to the next person and (s)he can adjust where needed, without having to look for some components/footprint differences.
>> Of course, its export, so the component would still live in the system library to be re-used.
>>     
> You just described the current 'cache' library system :D
>   


I would like to introduce a new term to describe the concept that I am
trying to convey:  "parts list".

parts list:  is a eeschema collection of unique parts that are used
within a particular schematic and is very much like a library, very much
like the existing cache library.  However, a parts list is a far more
visible and accessible list that *must* hold the programmatic factory
mechanism for instantiating any component on that schematic.  The parts
list holds no duplicates, only a single description of each unique
part.  When a component is *instantiated*, it's genesis *must* reside in
the parts list for the schematic, and the *only* things that get
assigned to the component instance during instantiation are reference
designator and location.  There are no additional, instance specific
fields or properties.  Please read that again.  The only things that
gets set during instantiation are the reference designator and the location.

A parts list could have a spreadsheet like editor, for columns that are
for the various properties within a parts list.  We should add the
concept of template field names to the parts list.  (The parts list
exists *within* the schematic.)  The parts list could have its own field
names, aka properties, aka columns in the spreadsheet editor, that would
be applicable to all parts in the parts list.

Yes I know requiring a parts list to be built up before instantiation
can take place is arguably an extra step, depending on the UI.  However
some injection into the parts list could be automated, at least on the
first usage of a particular part, but there could be more obvious ways
to manipulate a parts list, and ultimately the UI determines the ease of
usage.  Drag and drop has been mentioned, in this case from any library
to the parts list.

In summary a parts list is basically a built in library, but one with a
special face on it.  Its presence ensures that any EESCHEMA schematic is
fully self describing, and it allows easy BOM creation because the
schematic components get stripped of all their current
fields/properties.  They only need to hold reference, location and part
id.  A part id is a navigator into the schematic's internal parts list,
such as a pointer.


The loss of component instance specific properties is actual a gain in
this case, because any edit to a part in the parts list will apply to
all component instances that are based on that part.


So the flow of design information is:

  library symbol -> parts list part ->  schematic component


Just curious, has then been done before in any other schematic
software?  (The answer to that question will not necessarily determine
if this is a good idea.)


Dick