kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

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