kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

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
>>> 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
> 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
implementing changes.

> 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. 
>
> hauptmech