kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 10/2/2010 6:30 AM, Vesa Solonen wrote:
> On 01.10.2010 23:42, Wayne Stambaugh wrote:
> 
>> 5) Drop support for creating components with alternate body styles (DeMorgan).
> 
> Would this mean we also lose the possibility of representing a component
> with multi part symbol and combined symbol? For example some
> microcontrollers fall in between where representation with one symbol is
> almost too difficult, but port level splitting is not always needed. How
> about opamps and comparators with or without power pins? Also style
> flexibility, like IEC / old ANSI / user defined style, etc. Embedding
> multiple versions of symbols to the library would be a very useful
> feature. Otherwise we need to define a policy how and when to split very
> large components regarding symbols. Just to mention I hate policies very
> much, but like flexibility. Naturally I'm willing to make compromises if
> flexibility means too much complexity or implementation cost. I may not
> understand everything correctly here, so please feel free to advice ;)

There would be no change in defining multiple parts per package symbols
for components such as op-amps and logic gates.  I am proposing that we
split the current libraries with alternate body styles (DeMorgan) out
the into two libraries.  One library with the standard symbols and one
with the alternate symbols.  I'm not sure but this may only effect the
74xx.lib.  My reasoning is that when you open a library and view a
component, you expect to see how the component will be drawn in your
schematic.  In the current design, you must enable displaying the hidden
alternate body style.  It isn't ready obvious to a user that this other
body style even exists.  I would rather open a library named
74xx_demorgan.lib and see the components displayed the same as they will
be when I place one in my schematic.

> 
>> 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 )
> 
> I like the compact approach, but maybe a "doc header" could contain the
> library grammar. Would it make sense to define a non parsed comment
> area? Is pin and functional block swap is one level deeper, so it was
> left out from this discussion?

I'm pretty sure adding a comment block at the top of library file can be
accommodated.  I just chose to show an arc as an example.  Once I finish
up the file format document, the rest of it will make more sense.  We
can discuss comments, pins, and functional block when I publish it.  I
just wanted to get a feel for what everyone's preference was so I can
finish up the document.

> 
> Thanks Wayne, for reworking the library. It's the cornerstone you
> mentioned and will enable lots of usability enhancements.

Thank you for your input.

Wayne

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