kicad-developers team mailing list archive

[Clemens Koller <cko@xxxxxxxxx>]

Hi, Chris!

On 2016-08-02 01:09, Chris Pavlina wrote:
> I'm in favor of power connects as labels because, well, that's what they
> are! Remember that power components and global labels behave
> identically. IMO keeping this consistency is very, very good from a user
> interface perspective - components in general don't make connections to
> remote places, that's what labels are _for_. The idea of a special type
> of component that behaves like a label really does not sit right with
> me.
> 
> It's also a quicker, more direct way to place a power port; there's no
> need for the separate edit step.

I fully agree with you here!

> Editing the value is a compromise I wouldn't be too upset about
> accepting, though I still think my way is better ;)

In medium/big designs I am sometimes having 10..20 different power nets
and a couple of different GNDs. I don't care about using different symbols
anymore as there would be just too many different ones to remember.
All the netnames are visible next to the symbol.

I am using a symbol (arrow up) with a label saying: +3.3V +5V, +1.8V, +1.0V, +VREF, ...
There is another one (arrow down) with a label saying: -5V, -VREF, ...
And then, off course the GNDs, GNDE, GNDA, GNDPE, ...

A great feature would be to automatically choose the power symbols depending on
the name of the net. So:
1. Hotkey (to add power Symbol)
2. Enter a net name first (Return)
3. When the netname starts with a + -> arrow up.
   When it starts with a - -> arrow down.
   When it starts with a G -> GND Symbol
Attach the symbol to the mouse pointer. Place it with single click/spacebar.

Still it would be nice to be able to disable visibility depending on netname.
It would still be desirable to change symbols for certain nets.
A GND
 _|_ 
could then be still different from a GNDPE
_|_
///

Regards,

Clemens





> On Mon, Aug 01, 2016 at 01:42:05PM -0400, Wayne Stambaugh wrote:
>> 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
>>>>>
>>>>
> 
> _______________________________________________
> 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
>