kicad-developers team mailing list archive
Mailing list archive
Re: Component fields use case
Dick Hollenbeck <dick@xxxxxxxxxxx>
Thu, 01 Sep 2011 08:51:48 -0500
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:188.8.131.52) Gecko/20110805 Thunderbird/3.1.12
On 09/01/2011 03:33 AM, hauptmech wrote:
>> 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
>>> 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.
>> 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
> I think the design *is* the file (or files). Kicad and all the other
> tools manipulating the file are just user interface. This is part of why
> I use kicad.
> If the design was the kicad app internal memory, then you would be
> dumping that to some efficient and easy to maintain binary format in
> between work sessions.
> Anyway I'll just log my humble request as an active user that you guys
> change from one file format to the next in one big version change rather
> than a lot of little increments.
No, the pay is too low around here to try and improve the package without
> It's not the end of the world if you don't... I just stay with whatever
> the last working-for-me version there is until the changeover is
> complete; but it's nice to be able to take advantage of the GUI updates
> as they happen.