On 08/31/2011 03:20 PM, hauptmech wrote: > > On 31/08/2011 9:35 p.m., Wayne Stambaugh wrote: >> On 8/31/2011 12:16 PM, hauptmech wrote: >>> On Wed, 2011-08-31 at 09:23 -0500, Dick Hollenbeck wrote: >>>> On 08/31/2011 08:31 AM, hauptmech wrote: >>>>> >From the bzr log message is appears that fields not in the template list >>>>> will be deleted on exit from the component edit dialog. Or read >>>>> differently Fields with a null value and not listed in the template list >>>>> will be deleted (which seems to be the behavior when I play with it...) >>>>> >>>>> >>>>> I store quite a bit of component meta-data here in the fields which >>>>> either gets dumped to the BOM for automatic purchase order generation, >>>>> or get's manipulated via python scripts accessing the raw eeschema >>>>> files. >>>>> >>>>> >>>>> >>>>> Presently the file format uniquely identifies each field with an id >>>>> integer. So empty values for field name and field value are technically >>>>> not a problem. At least this was my assumption and it seems a reasonable >>>>> conclusion for anyone writing scripts against the .sch file. >>>>> >>>>> I happen to use the field name as a key for some things and so they are >>>>> unique, and non-null in my case. However there are lots of good reasons >>>>> to stick a null in the field value and automatically stripping fields >>>>> with a null value string would be undesired. >>>>> >>>>> I just noticed that if one of my field names is in the template it get's >>>>> shuffled in the order. Also template fields get inserted before existing >>>>> fields, and this order is being propogated to the field ID in the >>>>> file... This will break things external to eeschema. I don't mind if >>>>> they get displayed in a different order on screen but changing the ID in >>>>> the file is very bad so the source of that should be tracked down and >>>>> fixed. >>>>> >>>>> Regarding the fields template: In my opinion this should only be used >>>>> inside the library component editor. Once a component is in the library; >>>>> the component is *itself* a template for adding information to the >>>>> schematic. I don't think we want to be 'automatically' modifing the >>>>> components, making assumptions about the library creators intentions. >>>>> >>>>> I hope this is useful. >>>>> >>>>> -hauptmech >>>> Two weeks of my time wasted. >>>> >>>> Sheesh. I really cannot agree with a single thing here. >>>> >>>> Sorry. >>>> >>>> Life is too short for this. >>>> >>>> Use the template fieldnames, put all your fields in there, every last one >>>> of >>>> them, then if they are blank, they go away. Search for your fields by >>>> name. >>>> The number is going away, period. >>>> >>>> Dick >>> I can migrate the metadata in my 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 _______________________________________________ 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
