kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 10/2/2010 11:13 AM, Dick Hollenbeck wrote:
> 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:

I prefer the more verbose style as well for readability.

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

I have no objections to abbreviates as long as they are clear.

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

I'm guessing this is online somewhere.  I'll take a look at it and see
what parts of it make sense for what we are trying to do.

Wayne

> 
> Dick
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>