kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

Hey Simon,

On 1/1/2019 5:03 PM, Simon Richter wrote:
> Hi Wayne,
> 
> On 01.01.19 20:59, Wayne Stambaugh wrote:
> 
>> I have updated and published the symbol file format[1] for comment.
>> Hopefully there isn't too much to change.  The only thing to really
>> finalize is the internal units.
> 
> This would be an artificial unit for the file format, not necessarily
> the true internal unit (which I want to unify across the entire program
> as soon as feasible, but that should be independent from the file formats).

I'm not sure exactly what you mean by a true internal unit.

> 
> If we want to keep using the grid as a poor man's magnetic anchor, it
> would perhaps make sense to just state the grid size in the component,
> and then use integer grid coordinates in the file for anything that is
> electrically connected. Users could then standardize on whatever grid
> size they prefer, get warnings for mixing components with different grid
> sizes, and/or get the option to scale the component so it fits.

Once the new tool frame work is in place in the schematic and symbol
editors, this should be less of an issue.  We should be able to add pin
connection snapping so it doesn't matter if the pin is on grid other
than it may make for some really ugly schematics.  I'm not too worried
about that other than our standard libraries stick to a constant pin
position.

> 
> For graphical parts, we need finer resolution than the grid, but
> inaccuracies no longer matter, so we can just use floating point numbers
> here.
> 
> I have several feature ideas I'd like to add at later points, so it
> would be nice to have a format version number and/or a list of format
> extensions somewhere near the beginning.

I accidentally left that out but I will add a header similar to the
footprint file format which includes the file version time stamp.

> 
> The other thing I'd like to see are standard properties for tagging
> library conformance, so components that have been verified by library
> maintainers would contain the name, version and variant of the library
> conventions they have been tested against, and these tags would be
> removed when editing.
> 
> This will allow for easier tracking of components through format
> updates, for example the new format adds pin swapping hints, which
> presumably the next version of the KLC will require for parts with
> swappable pins, but doesn't now because the feature doesn't exist yet.
> 
> Converted parts from the old library would be marked as conformant with
> an older KLC version, so the differences between the KLC versions can be
> used as a checklist to bring the component up to the current standard
> without requiring a full recheck.

I'm not sure it's a good idea to embed this information in symbol
libraries because how would it be defined for a user (non-KiCad)
library.  It could give users a false impression that a library is an
official library if it's abused.

Cheers,

Wayne

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