Why not collect all the field of any part being loaded, and consider all the fields that are not known as “user defined fields”? I would not agree to have a part_reference to be the combination of two of my user fields that are Supplier1 and PN_Supplier1, Supplier2 and PN_Supplier2, etc.. Just keep those fields, that would allows the program to load ANY legacy part without breaking the bank.
Just my $0.02, Jean-Paul AC9GH On May 6, 2014, at 2:28 PM, John Beard <[email protected]> wrote: > I think it would be a good idea to allow unknown fields in the > s-expression formats so that an older KiCad doesn't choke on things it > doesn't understand, and doesn't need to. > > For example, I was thinking that it might be helpful to add a field to > the footprint format: "part_reference", which would hold a list of > manufacturer and/or vendor IDs associated with this part. For example: > > (part_reference (fci 343233222) (farnell 1234567)) > > Leaving discussions on the actual usefulness of this field aside, > clearly, an older KiCad does not need this field, it can be ignored > harmlessly. However, when saving a footprint, an older KiCad should not > remove this field. > > Ignoring *every* unknown field might also not be the best idea, in case > there is one day a field which an older KiCad can't understand, but > should realise "no, this means I can't use this footprint". So maybe > also a "fp_version" field, which, if missing, is assumed to be "1". > Then, if a future footprint declares "(version 2)", because it knows it > contains features a version-1 KiCad will misinterpret, that version-1 > KiCad can say "sorry, I'm version 1, you need version 2 or higher". In > this case, it would be nicer to not set the version to 2 if you didn't > need to, so version-1 KiCads can use the footprint. > > As it currently stands, *any* KiCad would refuse to load a footprint > with either of these fields, which is what I am proposing that we > change. The "part_reference" field is just an example, and needs more > thought. I was pointed to a discussion about a "device" concept, but > that is outside the scope of this. > > Cheers, > > John > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
