On 7/31/2016 4:45 PM, Wayne Stambaugh wrote:
> 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. :)
Sorry. I misread your suggestion although we do need additional
symbol
types. I'm not sure how power labels versus power components would
work. I would need more information on how they would behave. Do
they
replace power symbols or complement them?
>>
>>>
>>>>
>>>> - 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
>
