kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 7/31/2016 3:59 PM, Chris Pavlina wrote:
> 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

Michele is working on a tree view paradigm for the component editor so
that work is already underway.  I think we see some significant
improvements in that area soon.  I need to get the file format stuff
done first.  The tools to edit the new features can happen later.

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

Are you talking about the embedding or the linking?  If it's the
linking, the default would be embedded.  The linking would be optional.
Linking to external object is a valid method.  It's what we do now only
it's limited to the currently defined symbol libraries.  There are users
(few but they exist) who like to have their schematics (and footprints
in boards for that matter) track changes they make to symbols.  The
beauty of the making links optional is the responsibility for breaking a
design falls on the user not on KiCad.  Most users wont use links but if
we don't allow them, you can be rest assured someone will complain.  I'm
willing to forego the linking (it would make life easier) if no one
finds it useful.  Do other EDA packages allow linking?

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

I'm not 100% sure I want to tackle user defined units in files.  I see
too much opportunity for floating point rounding issues between files
defined with different units.  I understand the appeal but my gut tells
me it's implementation is fraught with peril.  I am more in favor of an
internal base unit and convert to user units on the fly like Pcbnew.  It
may be something we can discuss in version 2 but we already a long list
of new features to implement.

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