kicad-developers team mailing list archive

[Fred Cooke <fred.cooke@xxxxxxxxx>]

You can't improve anything without making changes, Dick. And his point re
breaking the API that exists (he's not the only one who has scripts against
your text files and prefers kicad for text file storage reasons) is valid.
Why the unpleasant attitude? :-/

On Thu, Sep 1, 2011 at 3:51 PM, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:

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