kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #06755
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