On 15 December 2010 13:49, Dick Hollenbeck <d...@softplc.com> wrote: > On 12/15/2010 06:19 AM, Brian Sidebotham wrote: >> On 14 December 2010 22:49, Wayne Stambaugh <stambau...@verizon.net> 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.)
No problem, I'm sure the more heads the better! > 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. This sounds very elegant, and a neat solution! As Wayne pointed out this means the definition of what constitutes a complete part can be decided upon later and can be subject to change as and when. Best Regards, Brian. _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
