kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 7/30/2016 9:22 PM, Chris Pavlina wrote:
> Hi,
> 
> I was reading through the new sch/lib format documents posted back in
> February: https://lists.launchpad.net/kicad-developers/msg23302.html
> 
> Since work is underway to facilitate adding this now, I figured it was a
> decent time to bring up a few concerns and suggestions I have. Bear in
> mind I'm working off a pretty old version of the document here - if it's
> been updated and some of this has changed, feel free to point me to a
> more recent version; I couldn't find one.

I don't believe I've changed it since the last time I published it on
the mailing list.

> 
> - I think we should work to reduce redundancies in the format. They just
>   confuse things and introduce parsing complexities (what happens when
>   A implies B, both are written to the file, and they don't agree with
>   each other?). Examples:
> 
>   - Why both 'polyline' and 'line'? Surely eeschema isn't going to get
>     tired of writing 'poly' and decide to start abbreviating it? Can't
>     we remove one?

Agreed. 'lines' could be one or more lines that may or may not form a
polygon.

> 
>   - Arcs have redundant information, we only need either (radius, start
>     angle, end angle, center), or (start point, end point, center). I
>     suggest sticking to the former and dropping the start/end points.

We currently save all of this information in the for an arc.  I'm not
sure why.  I'm fine with this proposal.  One advantage to using the end
points rather than the angles is round errors to ensure completely
enclosed drawings but I don't know if that is an issue or not.

> 
> - Can we consider adding power ports as a type of label rather than
>   component, so we don't have to maintain libraries of every possible
>   rail name anymore? I'd happily contribute to the implementation - I
>   have an old feature branch where I did exactly that, it worked really
>   well :)

I thought that was in there already.  Maybe I missed it.  There will be
a symbol type token.  We have to support normal, power, virtual (show up
in BOM but not netlist, could have a better name not-in-netlist?), and
not-in-bom? (for net ties at a minimum, maybe net-tie would be a better
name but it could be used for other not in BOM objects that we have yet
thought of).

> 
> - There's a vague comment that fonts aren't supported yet but may be in
>   the future. We should specify *now* how upcoming pre-font versions of
>   kicad should handle future files that have been saved using fonts, and
>   make sure they actually can.

Yep, that code will need to be tested.  The EDA_FONT object already can
format itself to s-expr it just hasn't been tested yet.  Now that
freetype is a dependency, I'm hoping we can do some more interesting
things with fonts in PCBs.  In schematics, custom fonts are less
problematic other than the age old issue of font availability.

> 
> - It looks like the new format may allow an arbitrary number of
>   "alternates", not just the one "De Morgan equivalent" that we allow
>   now. Is this true? I'd love that.

Yes, don't see any reason that there is only a single alternate body
style.  It will require changes to the component editor.

> 
> - Can we ditch 'keywords'? It's not useful anymore, the new component
>   search doesn't use it and does a fine job of sifting through tokens in
>   descriptions.

We may not want to throw them out.  They could be useful for third party
tools.  I'm thinking tags here which is probably a better token than
keywords.  I'm not dismissing this idea but I have a feeling that they
could prove useful.

> 
> - "Are there any other per net hints besides net classes?" - we should
>   allow them! They're just hints - allow the format to have arbitrary
>   ones that will just be ignored by a pcbnew that doesn't understand
>   them.

They are called properties in the board file format and they can be
define in any object.  I plan on using that same paradigm in the new
schematic file format.  Properties are for third party tools which kicad
knows nor cares anything about.  AFAIK there is no limit to their use or
definition and they are simple key/value pairs.

> 
> - Can we add controllable line _color_ as well as style? And also for
>   wires? (people making wiring diagrams will like that.)

I don't see any reason not to add an optional color expression to all
objects where it makes sense.  Of course the code will need to be added
to the objects (EDA_ITEM?) themselves and fall back to the defaults when
no color is defined.

> 
> - BUG: bus_entry is missing an angle specifier - it's possible to
>   rotate/flip them.

Good catch.

> 

A few more that didn't make it into the latest spec but I'm planning on
implementing:

* Embedded components with an option to link.  Initially linking will
only support internal linking but eventually it will grow to support
other external linking such as file, ftp, http, etc.  The link format
will be a uri.  For internally linked components the format will look
something like sch:\\SCH_NAME\COMPONENT_NAME.

* I am considering forgoing the unitless idea at least in the first
pass.  As much as I like the idea, the task of implementing it would be
monumental and I just don't want to change that much of the Eeschema
internals in one shot.  I'm already having to make way more changes than
I'm comfortable with to support the new I/O plugin.