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