kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 8/2/2016 7:16 AM, Chris Pavlina wrote:
> My implementation had a large number of symbols, would have allowed
> user-supplied arbitrary symbols if I had finished it, and automatically
> selected a symbol based on net name _exactly_ as Clemens suggested. All
> of these issues are solved.

How difficult would it be to apply the same selection criteria for power
symbols?  The more you explain what you have done with power label the
more it seems like you could have done the same thing with power
symbols.  This would save implementing a new object and the file
formatting to support it.  Maybe I'm missing something here but I just
don't see how a new label type that looks like a power symbol is
different from a power symbol that already provides the same functionality.

FYI, we are spiraling into a feature discussion rather than a file
format discussion.  Please keep the discussion focused on what needs to
be added to the new file format.  Without the file format changes, the
features are meaningless.

So far here is the list of new file format features I am planning to
implement:

- Pin and gate swapping and mapping (defined).
- Differential pair definition (undefined).
- Net class definitions. (undefined other than what we have in the board
file format)
- Font definition for text objects (defined).
- Custom colors for all drawing objects (undefined but trivial).
- Embedded and linked symbols (undefined but I've already have a
definition in mind).
- Custom properties for objects (defined, same as board file format).
- Support for more than 2 body styles (defined).
- Symbol types: normal, power, virtual (in BOM not in netlist), and
net-tie (defined except for additional net-tie requirements).
- Per file symbol library design (defined like the pretty footprint
libraries).
- Custom pads (undefined).

Here is the list of possible features that I haven't made up my mind
about yet:

- Custom file units.
- Layers.

Please keep in mind, support for a feature in the new file format does
not mean that that feature will magically appear.  I'm only signed up to
write the file parser and formatter and add any object support for the
new features.

> 
> On Tue, Aug 02, 2016 at 10:00:51AM +0200, Clemens Koller wrote:
>> Hello, Chris!
>>
>> On 2016-08-02 09:19, jp charras wrote:
>>> About shapes: an arrow and 2 gnd symbol shapes is not enough.
>>> 3 or 4 shapes only is a serious regression.
>>> A lot of shapes is what we have now.
>>
>> I was not suggesting to remove/reduce shapes.
>> I prefer using only a few of the shapes and turn on netnames
>> most of/all the time to be able to distinguish them
>> because there are so many different power/gnd-nets.
>>
>> What I always want to reduce is the no. of keystrokes/clicks,
>> because in big designs, it matters a lot or even most!
>>
>> Regards,
>>
>> Clemens
>>
>> _______________________________________________
>> 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
>