kicad-developers team mailing list archive

[Chris Pavlina <pavlina.chris@xxxxxxxxx>]

On Sun, Jul 31, 2016 at 03:25:11PM -0400, Wayne Stambaugh wrote:
> 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.

Very good point about the start/end points. eeschema doesn't currently
support that - it can't fill enclosed regions that are enclosed by
multiple graphical objects - but this would ensure it could in the
future with minimal changes. Okay - I'm for using start/end instead of
angles, then. I'd still like to get rid of the redundant info, though.

> 
> > 
> > - 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).

Hm, I don't see it if it's there. I'm not entirely sure what I'm
imagining you describing, here. Anyway, I think I'll drop this briefly,
and then later resurrect that feature branch I had and start some
discussion. I had quite a bit there, including UI work, that was quite
slick IMO. :)

> 
> > 
> > - 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.

Nice. And while I see where you're coming from (and agree) about custom
fonts being less useful in schematics, I think if we did implement that,
it would prove very popular. One BIG benefit would be the ability to
properly support arbitrary Unicode characters.

> 
> > 
> > - 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.

Yup. I'd like to see the component editor changed anyway, ideally by
nuking from orbit >:D

> 
> > 
> > - 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.

Fair enough.

> 
> > 
> > - "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'm not sure how I feel about this. I like the idea, but I'm not sure
how this would work from the user's perspective. I can't really think of
something that wouldn't be a big pain.

> 
> * 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.

YES. I'm 100% for dropping unitless. It's already caused some headaches
with people wanting to conform to standards that require things in
certain units. What I would like to see, though, is eeschema no longer
depending on specifically imperial units - I get that the libraries
would be designed around one unit system or the other, but I'd like the
option to make a custom set of libraries in metric, for instance.

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