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