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@lists.launchpad.net >>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>>>> More help : https://help.launchpad.net/ListHelp >>>>> >>>> > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
