kicad-developers team mailing list archive
Mailing list archive
Re: Component fields use case
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
>>> 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
>>> 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.
>> Two weeks of my time wasted.
>> Sheesh. I really cannot agree with a single thing here.
>> 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.
> 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.
>> 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