kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 09/24/2010 08:59 AM, Dick Hollenbeck wrote:
> 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
>   


Then if you give EESCHEMA the ability to treat any previously designed
schematic as a library source for a new schematic (remembering that a
parts list is a library that exists within a schematic), you can pull
from one parts list into a new one, using drag and drop also.  If you
want to extend this to the extreme, you can eventually do away with
library files in total and only have one file format, schematics.  This
extension is a separate optional design decision obviously.  You could
also do this and hide it by giving the libraries a different file
extention, but the formats could be identical.  Library files would not
need to have any component instantiations or wires.


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