On 12/15/2010 1:20 PM, Simon Rogers wrote: > Hello, > > Firstly thank you all for the amount of work and effort you have put into > this. > I have recently started to use Kicad and found it a very good tool. > > I had a look through the spec last night and followed the thread below with > interest. I'm looking forward to the new lib system as I've found the current > one limiting. > > A couple of ideas for the melting pot: > > 1. Reading the thread below it occurred to me that an alias tag might be > useful > - something like > > (pin (number "4") (name "D")) > becomes > (pin_rename "4" "D") > or > (pin_alias "4" "D") > > The idea is that the user could toggle alias's on or off to see both pin names > should they want to.
I would think opening the base part file would be a more appropriate action. You could get into a situation where you may have 4 or 5 levels of inheritance and trying to display all of the names in the derived part could be get very cluttered and confusing. > > 2. The other idea is an ignored section i.e. > (ignore text_to_be_ignored) > > The idea is that you could then put some info meaningful only to you into this > section and the lexer would happily ignore it - maybe use $Id:$ for svn > version-ing. > > 3. For the visibile field if instead of "yes" and "no" it was "100" and "0" to > represent transparency it might enable a nice feature later. > ie. > instead of > (visible yes) or (visible no) > we would be able to have > (visible 100) or (visible 0) or (visible 25) This is what the effects element is for. I didn't use it the examples so it may not be exactly clear how it works. Effects determine how or even if a property is displayed. If a property has no effects, it is not shown. Effects can also be used to change how a property in the base part is drawn when a part is inherited. I don't know that transparency is as useful in the schematic editor as it is in the PCB editor but I am not against adding it to the specification. Anyone else have any thoughts on this. Wayne > > Will read through again tonight. > > Regards, > Simon > > On 15/12/2010 16:13, Brian Sidebotham wrote: >> On 15 December 2010 14:41, Wayne Stambaugh<stambau...@verizon.net> wrote: >>> On 12/15/2010 7: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. >>>> >>>> Ah, actually, I see you might be using the value field for this >>>> purpose. Only values are selectable parts perhaps? >>>> >>>> (2) I could see a pin rename function being handy. At the moment it is >>>> possible to delete a pin and then add a new pin in, but this would >>>> mean re-defining all of the other pin properties. >>>> >>>> (pin_rename NUMBER NAME) >>>> >>>> Another method might be to have overriding of pin attributes. For example: >>>> >>>> (part “dual_input_nand_a” >>>> (reference “U”) >>>> (pin input line (at -600 100 180) >>>> (name “” (font (size 60 60)) (visible yes)) >>>> (number “1” (font (size 60 60)) (visible yes)) >>>> (visible yes)) >>>> ) >>>> >>>> (part “dual_input_nand_b” inherits “dual_in_nand_a/rev1” >>>> (pin_del 7) >>>> (pin_del 14) >>>> (pin_renum 1 4) >>>> (pin_renum 2 5) >>>> (pin_renum 3 6) >>>> (pin (number "4") (name "D")) >>>> (pin (number "5") (name "E")) >>>> (pin (number "6") (name "F")) >>>> ) >>> Brian, >>> >>> Pin renaming makes sense to me. I would like to keep the item_action >>> concept >>> for consistency. In other words: >>> >>> (pin (number "4") (name "D")) >>> >>> becomes >>> >>> (pin_rename "4" "D") >>> >>> If you don't have any objections, I'll update the specification. >>> >>> Wayne >> Hi Wayne, >> >> Yes I think that is the best and neatest method, I'm sure it'll be useful. >> >> Many Thanks, >> >> 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 > > _______________________________________________ > 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 > _______________________________________________ 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
