← Back to team overview

kicad-developers team mailing list archive

Re: Library structure recap.


On 10/02/2010 10: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:
> 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

A couple of more thoughts:

1) this is a balancing act, and I think that during the evaluation
phase, the implementor, i.e. you, should feel mostly in control of the
blending in and weighing of the issues and opinions of others.

2) Brainstorming is a good phase to go through, during this phase we
don't say what is good or bad, we simply collect ideas for *later*

Many folks have never been taught the formal art of brainstorming, and
even among those that have been taught, exercising the discipline of not
expressing judgment too early can be a stumbling block, me included.

I like that you have already put some things on the table for

I have always felt that it is hard to find the best solution if only the
first solution that comes to mind is adopted.  This seems to be human
nature, solve the problem with the first idea.  We all as engineers are
skilled problem solvers, so we are often viewed as strange ducks in
society.  IMO the formal art of brainstorming is not getting its due in
our school systems, but engineers seem to be a little bit better at it
than most.


Follow ups