← Back to team overview

kicad-developers team mailing list archive

Re: Component fields use case

 


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

> Wayne
>
>> Hauptmech
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


Follow ups

References