kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 10/2/2010 2:37 PM, Vladimir Uryvaev wrote:
> I have some thoughts about.
> 
> Wayne Stambaugh:
>> Since the discussion has died down on the library structure.  Here is a
>> recap of the discussion.
>>
>> 1) The current concept of component will be replaced by symbol which is the
>> graphical representation of a component.
> 
> I really like it, if it will allow me use same symbols with different pinouts 
> (like in CD4000/74xx00/74xx1G series) and set rules for gate/pin swap and 
> power pins.
> 
> Also there's may be very useful feature to place just symbols on schematic, 
> and bind them to components later. For example, one would be able to join set 
> of resistors to single chip resistor networks.

This behavior would be defined by the schematic editor and schematic
file structure not the library file structure.  Although it is certainly
something to consider.

> 
>> 2) The current concept of aliases will be replaced by component which will
>> contain it's own fields but can share a symbol with other components to
>> save memory.
> 
> The reason is not only to save memory, but save designer's worktime on copying 
> symbols everytime correcting them.
> 
>> 3) Symbols may be shared among all components within a library definition. 
>> In other words, symbols will not be shared across libraries.
> 
> Why not? I would like to share diode, transistor etc symbols between huge 
> amount of libs, sorted by manufacturer/prefix. I dislike to make a copies so 
> much.

Complexity is the main reason.  Adding an extra search path to find a
library symbol will create addition complexity to both the library
structure and the schematic structure.  A well design copy and paste in
the library editor should minimize the need to share symbol across
libraries.

> 
>> 4) Merge the separate document file (.dcm) information into the new library
>> file format.
>>
>> 5) Drop support for creating components with alternate body styles
>> (DeMorgan).
> 
> I very liked De-morgan styles, hovewer it's not vital necessity. It would be 
> very well if there will be some alternate solution. For example, i use AND-NOT 
> and NOT-OR symbols in single chip.
>>
>> 6) Library files will be S expressions using richio.
>>
>> 7) Proper copy/paste should be added to the library editor to simplify
>> library creation.
>>
>> 8) Improve component browsing (drag & drop?) for adding components to
>> schematics.
> 
> I think it is not touching library format.
> 
>> I will volunteer to complete the following:
>>
>> 1) Refactor component library objects to support the new library structure
>> while maintaining backwards compatibility for reading the current file
>> format.
>>
>> 2) Write the code to read from and write to the new file format.
>>
>> 3) Make writing new file format a build option until it is ready for
>> production.
>>
>> 4) Back up current format library files to user_defined_file_name.lib and
>> user_defined_file_name.dcm when saving library to new file format.
> 
> Better use another name extension (like .schlib), .lib is so threadbare to use 
> (this also for .mod of course). So old libraries are backed up automatically 
> when saving in new format.

It would be just as easy to change the file extension instead of backing
up the old file to a new file name.  I don't have a strong opinion on
this one way or another.

>  
>> 5) Create a separate library user_defined_file_name.lib when libraries are
>> found containing alternate body styles (DeMorgan).
>>
>> 6) Merge the footprint list into the FOOTPRINT field and the data sheet
>> definition string to the DATASHEET field in the new library structure.
>>
>> 7) Update the component editor to reflect the changes to the new library
>> structure.
>>
>> I will not be adding the copy/paste to the library editor or changing the
>> component browser as part of this.  My goal is to get this done by
>> Thanksgiving so I want to keep the task reasonable.
>>
>> Before I submit the new file format document for comment, would you prefer
>> a more readable but larger file format:
>>
>> ( arc
>>   ( start_point 1000 1000 )
>>   ( end_point 1500 1500 )
>>   ( start_angle -45.0 )
>>   ( end_angle 45.0 )
>>   ( unit 2 )
>>   ( line_width 1 )
>>   ( fill_type none )
>> )
>>
>> or a less readable but more compact file format:
>>
>> ( arc ( 1000 1000 ) ( 1500 1500 ) -45.0 45.0 2 1 unfilled )
> 
> I like the rule to use 'short' for arbitrary arguments and 'long' for 
> optional. For example there's not need to set 'line_width' if it is default.
> 
> Like:
> (arc 1000 1000 1500 1500 45 (unit 2) (width 1) (fill none))
> 
> Anyway it is not necessary for user to read library files.
> 
> But, stop. What's the unit in the SYMBOL?

The unit is used when defining symbols with multiple parts per package.
 Think 4700 here.  This will be more clear once I publish the library
file format document.

Wayne

> 
> About arcs.
> Only 5 parameters enough to describe an arc. They would be
> * center_x; center_y; radius; start_angle; end_angle;
> or
> * start_x; start_y; end_x; end_y; bend_angle;
> or some else.
> Also second set of parameters can also describe straight line, if bend_angle 
> is 0, so there's no need to make separate line and arc types in format.
> This also should make arcs easily become polygon parts, so one can draw ANSI 
> NOR symbol filled.
> 
>> Let me know and I will make the necessary changes to the file format
>> document.
>>
>> Wayne
> 
> Thank you for your work.