kicad-developers team mailing list archive

[hauptmech <hauptmech@xxxxxxxxx>]

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

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
> 
> 
> _______________________________________________
> 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