kicad-developers team mailing list archive

[Vladimir Uryvaev <vovanius@xxxxx>]

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.

> 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.

> 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.
 
> 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?

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.
-- 

--- KeyFP: DC07 D4C3 BB33 E596 CF5E  CEF9 D4E3 B618 65BA 2B61

-- 

--- KeyFP: DC07 D4C3 BB33 E596 CF5E  CEF9 D4E3 B618 65BA 2B61