kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 12/15/2010 9:51 AM, Dick Hollenbeck wrote:
> On 12/15/2010 08:46 AM, Dick Hollenbeck wrote:
>> On 12/15/2010 08:35 AM, Wayne Stambaugh wrote:
>>> On 12/15/2010 8:49 AM, Dick Hollenbeck wrote:
>>>> On 12/15/2010 06:19 AM, Brian Sidebotham wrote:
>>>>> On 14 December 2010 22:49, Wayne Stambaugh <stambaughw@xxxxxxxxxxx> wrote:
>>>>>> I made some ,inor changes to clarify inherited vs base part and changed
>>>>>> LPID names reflect local naming convention as suggested by Dick.
>>>>>>
>>>>>> Wayne
>>>>>>
>>>>>> On 12/14/2010 9:39 AM, Wayne Stambaugh wrote:
>>>>>>> I know all of you've been on the edge of your seats waiting for the the new
>>>>>>> part file format since Dick announced his plans to start working on the
>>>>>>> distributed library.  So without further ado, attached is the preliminary copy
>>>>>>> of the library part file specification.  Please take a look at it and make sure
>>>>>>> I didn't forget anything.  I have tried to accommodate all of the previous
>>>>>>> library discussions as best I could.  If I missed something, it wasn't
>>>>>>> intentional so please let me know so I can revise the specification.
>>>>>>>
>>>>>>> Initially, I would like keep the discussion focused on what is missing and how
>>>>>>> it should be implemented.  Please keep the discussion on semantics like "I
>>>>>>> would rather use thickness instead of line_width" until after we've hammered
>>>>>>> out all of the technical issues.
>>>>>>>
>>>>>>> Once we have a consensus, I will convert the document into a more formal format
>>>>>>> similar to the current file specification documents and commit it to the
>>>>>>> documentation repo since that is were the rest of Kicad's documentation resides.
>>>>>>>
>>>>>>> I know it's been a long time coming so thank you for your patience.
>>>>>>>
>>>>>>> Wayne
>>>>> Hi Wayne,
>>>>>
>>>>> I just got a look through the doc. I have a few questions/observations for you:
>>>>>
>>>>> (1) If I browsed a library for a part which contains all of the parts
>>>>> information below the line:
>>>>> # This is an example of a dual input NAND gate A of a 7400.
>>>>> in the document, does this mean that I would see all of the parts for
>>>>> selection? i.e. dual_input_nand_a, dual_input_nand_b,
>>>>> dual_input_nand_c, dual_input_nand_d, dual_input_nand_demorgan_a,
>>>>> dual_input_nand_demorgan_b, dual_input_nand_demorgan_c,
>>>>> dual_input_nand_demorgan_d, 7400, 74LS00, and SN74HCT00NSR
>>>>>
>>>>> I would have thought there would need to be a way in the syntax of
>>>>> showing what was a selectable/finished part and what was merely a
>>>>> "symbol" or partial part which should not be allowed to be entered
>>>>> into the schematic directly.
>>>> Brian,
>>>>
>>>> This is a good observation, about the readiness of a part.  (Don't mean to butt in,
>>>> since you asked Wayne.)
>>> Brian,
>>>
>>> Good catch.  I hadn't actually thought about that.
>>>
>>>> Three possible solutions to keeping a part off limits for instantiation:
>>>>
>>>> 1) Mark the part as not ready for prime time using Sweet.
>>>>
>>>> 2) The part parser is dancing through all these part body expressions.  Rather than
>>>> the user saying in syntax that the part is not ready for primetime, it may be possible
>>>> for the parser to reach such a conclusion and then reflect this in a class PART::state
>>>> field, indicating that it is syntactically correct, but incompletely specified.
>>> My preference would be solution 2.  If we change our minds as to what defines a
>>> valid part, we only need to change that in the library code.  If we implement
>>> it as a new part file element, we would have to change it in every part file.
>>> It also creates additional syntax for the part file.  One of my primary goals
>>> was to keep the part syntax as clean and readable as possible so I will be
>>> reluctant to add anything that can be solved in code.  It should be easy enough
>>> to have the librarian only display valid parts for inclusion into a schematic.
>>>
>>> Wayne
>> Right, I should have given my 4th solution a number 4).  Definitely 2) is needed, and
>> the good news is 2) and 4) are not mutually exclusive.  You could not implement 4)
>> without 2).
> 
> Since the parts list is the origin of the BOM, we may need to have 4) also, other wise
> folks will go to buy incomplete parts and get all confused.  :)
> 
> Worse yet, they may come back and ask us where to get those parts.

It's really difficult to find a good supplier for arcs, rectangles, and lines,
let alone bezier curves :)

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