kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

How is this different or better than being able to edit a power
component value?  I know we cannot do this right now but I see no reason
that it couldn't be done once the new file format is in place and power
components are defined by component type rather than naming semantics.

On 7/31/2016 5:09 PM, Chris Pavlina wrote:
> Power labels replace power components. Here are a couple screenshots
> from my feature branch that I dug up - still haven't actually got it
> building again, it had a few issues, but the screenshots should explain.
> Bear in mind they're all at different levels of development, so I don't
> necessarily mean things should be *exactly* like this.
> 
> https://misc.c4757p.com/power.png
> https://misc.c4757p.com/powereditor.png
> 
> I implemented them as a subclass of global labels, with a modfied draw
> method that would render a library part instead of a text label. I then
> embedded a library of standard power symbol styles so the user could
> simply select one, and added a property to the labels to record their
> style. Future plans included the ability to use user-supplied styles,
> edited by the library editor.
> 
> It's not immediately obvious from the screenshots, but the UI had
> heuristics to pick a sensible style based on the net name you typed, so
> power labels could be placed very quickly by pressing the hotkey (I just
> repurposed P), typing the power net name and hitting enter.
> 
> Allowing user-supplied styles would allow backwards compatibility with
> old schematics: old-style power components in those schematics could be
> simply converted to power labels using that component as the style; no
> visual or logical difference would occur.
> 
> On Sun, Jul 31, 2016 at 04:59:53PM -0400, Wayne Stambaugh wrote:
>> 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
>>>
>>