On 09/01/2011 03:33 AM, hauptmech wrote: >> libraries from what they are now to >>>>> key-value pairs in a new file format. And I can deal with that file >>>>> format not handling null strings. >>>>> >>>>> But it's a bit rough on those of us using kicad to pull the rug out from >>>>> underneath us by jiggering the existing file format. If you aren't >>>>> releasing the next stable version until after there's a new file format, >>>>> fine. But otherwise... ouch. >>>> The the addition of field templates did not change the current file format >>>> AFAIK. What I'm not sure of is if you define a field in library component >>>> that >>>> it's value is copied into the schematic component field when that field >>>> name is >>>> already defined in the template list. As for the forthcoming file format, >>>> it >>>> should be transparent to the user that the file format has even changed. >>> Hmm, I hadn't payed attention to the field template when it was >>> introduced because it's not useful to me. The present stable version has >>> the same behavior: >>> >>> When a template field matches an existing field, and component >>> properties are edited in eeschema, it inserts the existing field at the >>> beginning of the non-reserved ones (id 4) and re-numbers all subsequent >>> fields. >>> >>> Subsequently generating a BOM shows that the components fields are >>> scrambled because the BOM generation uses ID rather than the field name >>> to organize columns. >>> >>> ... >>> >>> Apparently as long as I leave the field templates empty it leaves the >>> component fields in the same order as read which is why we haven't >>> noticed any problems during board production. >>> >>> Now that I know the devil and it's nature, I'm happy to let it lay where >>> it is. Under the specific conditions I use it, it does not damage the >>> libraries, schematics, and production scripts I use, so it's not a >>> problem for me. You guys should consider putting a warning on the field >>> templates form though until the new format comes. >>> >>> Regards, >>> >>> Hauptmech >> Kicad is not a word processor. We intend to preserve a design as the file >> format evolves, not what the design looks like on disk. >> >> Your best bet is to take a look at the generic netlist export, which is in >> XML. >> That format we hope to preserve, while the world around it might morph, for >> good >> cause. >> >> Dick > I think the design *is* the file (or files). Kicad and all the other > tools manipulating the file are just user interface. This is part of why > I use kicad. > > If the design was the kicad app internal memory, then you would be > dumping that to some efficient and easy to maintain binary format in > between work sessions. > > Anyway I'll just log my humble request as an active user that you guys > change from one file format to the next in one big version change rather > than a lot of little increments.
No, the pay is too low around here to try and improve the package without implementing changes. > It's not the end of the world if you don't... I just stay with whatever > the last working-for-me version there is until the changeover is > complete; but it's nice to be able to take advantage of the GUI updates > as they happen. > > hauptmech _______________________________________________ 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