kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 10/01/2010 03:42 PM, Wayne Stambaugh wrote:
> 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.
>
> 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.
>
> 3) Symbols may be shared among all components within a library definition.  In
> other words, symbols will not be shared 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).
>
> 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 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.
>
> 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 )
>
> Let me know and I will make the necessary changes to the file format document.
>   


I think in order for the file to achieve one of the main objectives that
is driving the change, we need to achieve the "self documenting"
objective.  If the new file is self documenting, then a person should
never have to refer to a separate "grammar document" to understand what
the file is presenting.  He may need a grammar document to write the
file, but not to read it.

So between the two choices you have given, I'd prefer the first choice,
by far.   There is a region in the middle however, and this is
approached by having conciseness in the keywords.  For example you could
shorten start_point to:

a) start_pt or
b) start  # if it's obviously a point

But if we go too far in this direction we end up where we started, with
single character mysteries and numbers without any introductory keyword.

In rare cases a single character could be meaningful, but you have to
wonder:   (x 12.3) (y 20.9)  when this will be true.  A "point" could be
understood to have an x and a y and that x comes before y, for example.

Overall I have been very impressed with the choices made in the specctra
dsn spec.  There could be small keyword oriented building blocks that
you might find helpful in there.

Dick