kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

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<stambaughw@xxxxxxxxxxx>  wrote:
>>> On 12/15/2010 7: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.
>>>>
>>>> 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@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 
> _______________________________________________
> 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
>