Wayne, The patch includes a minor refactoring of a function that ended up not being necessary in the end - originally my code made changes to it that were hard without refactoring, but I ended up reworking my code and didn't need that function anymore. I didn't revert the refactoring, as it worked well and was cleaner. However, if you notice any issues with FOOTPRINT_EDIT_FRAME::Import_Module(), let me know, I will revert the changes and send you an updated patch.
On Mon, May 02, 2016 at 11:46:34AM -0400, Wayne Stambaugh wrote: > Chris, > > Give me some time to test your patch. I will apply it to all of my > systems and test it to make sure it doesn't break anything. > > Thanks, > > Wayne > > On 5/1/2016 6:59 PM, Chris Pavlina wrote: > > Followed up on this question in a separate mail. > > > > Patch is attached. Please have a good look over it, if it's going to stable > > I > > don't want to be the only one who's had a look :) > > > > On Sat, Apr 30, 2016 at 07:57:36PM -0400, Chris Pavlina wrote: > >> I'm very close to finished - I'll take some time to fully test and review > >> the > >> patch to ensure it's ready for a commit to stable, though - will submit > >> tomorrow. > >> > >> I have a question. Currently, when loading a full library as opposed to a > >> single footprint, we silently ignore errors and just do not load footprints > >> that have syntax issues. This of course means that format versioning won't > >> really work for these. The user will never see the hint about their version > >> being old. > >> > >> Should I: > >> 1) Leave it as is. (please say no please say no please say no) > >> 2) Make an exception for the version-too-new case. > >> 3) Change this and *do* display these errors, in all cases. > >> > >> On Fri, Apr 29, 2016 at 09:24:19AM -0400, Wayne Stambaugh wrote: > >>> Thanks for the update. I've been holding off on releasing 4.0.3 for > >>> this. I apologize for my absence over the last week or so. I've been > >>> really busy at work and got sick on top of that so my motivation to > >>> spend what little free time I had working on KiCad was low. > >>> > >>> Cheers, > >>> > >>> Wayne > >>> > >>> On 4/28/2016 2:38 PM, Chris Pavlina wrote: > >>>> Just a quick ping to reassure y'all I'm still working on this - been > >>>> caught > >>>> up in other things a bit the last couple weeks. I've got a nearly working > >>>> implementation here. > >>>> > >>>> On Tue, Apr 12, 2016 at 12:22:48PM -0400, Wayne Stambaugh wrote: > >>>>> I doubt this going to be a big issue. Since the new board file format > >>>>> was implemented over fours years ago there have been a handful of > >>>>> changes. I think we're going to be OK with just the date code. > >>>>> > >>>>> On 4/12/2016 12:06 PM, Chris Pavlina wrote: > >>>>>> Let's just not do more than one format change in a single day... I > >>>>>> think that > >>>>>> would be a beneficial decision for project stability as well... > >>>>>> > >>>>>> On Tue, Apr 12, 2016 at 05:26:27PM +0200, Timofonic wrote: > >>>>>>> Despite my very limited knowledge, I like the simple approach. > >>>>>>> > >>>>>>> What about using letters if more than one format change is done? > >>>>>>> > >>>>>>> 20160412A, 20160412B, 20160412C... > >>>>>>> > >>>>>>> On April 12, 2016 2:30:23 PM CEST, Chris Pavlina > >>>>>>> <pavlina.ch...@gmail.com> wrote: > >>>>>>>> Honestly I don't see the advantage to using Semantic Versioning for > >>>>>>>> an > >>>>>>>> internal file format version... and using 2016.04.12 instead of > >>>>>>>> 20160412 > >>>>>>>> just seems like an exercise in making the parser more complicated. > >>>>>>>> Could > >>>>>>>> you explain *why* this would be a good thing? > >>>>>>>> On Apr 12, 2016 1:51 AM, "David Cary" <d.cary+2...@ieee.org> wrote: > >>>>>>>> > >>>>>>>>> Please at least consider Semantic Versioning ( http://semver.org/ ). > >>>>>>>>> And I recommend that if you figure out any way to improve on SemVer, > >>>>>>>>> please speak up so maybe the next version of SemVer can incorporate > >>>>>>>>> those improvements. > >>>>>>>>> > >>>>>>>>> I have enjoyed the discussion of new features and various ideas for > >>>>>>>>> versioning, and I encourage you to discuss them further. > >>>>>>>>> > >>>>>>>>> I am happy that the native KiCad file formats already avoid many > >>>>>>>>> problems mentioned in > >>>>>>>>> "Designing File Formats" > >>>>>>>>> http://www.fadden.com/tech/file-formats.html > >>>>>>>>> . > >>>>>>>>> Are there any remaining recommendations in that essay that maybe we > >>>>>>>>> should include in future versions of KiCad file formats? > >>>>>>>>> > >>>>>>>>> If hypothetically we did use Semantic Versioning, > >>>>>>>>> would it be better to do (a) or (b)?: > >>>>>>>>> (a) have a single KiCad version number that KiCad writes into every > >>>>>>>>> new file it creates, or > >>>>>>>>> (b) have a separate and independent version number for each part of > >>>>>>>>> KiCad -- the Eeschema version number written into new schematic > >>>>>>>> files, > >>>>>>>>> a separate Pcbnew version number written into new footprint and PCB > >>>>>>>>> layout files, etc. > >>>>>>>>> > >>>>>>>>> (How many independent version numbers could option (b) require?) > >>>>>>>>> > >>>>>>>>> On Thu, Apr 7, 2016 at 1:04 PM, Chris Pavlina > >>>>>>>> <pavlina.ch...@gmail.com> > >>>>>>>>> wrote: > >>>>>>>>>> What about using the date the change was made as a "version > >>>>>>>> number"? Can > >>>>>>>>>> integerize it like 20160407 for example. This allows easy > >>>>>>>>> cross-referencing of > >>>>>>>>>> a format version with the revision that it was made in, and is > >>>>>>>>> guaranteed to > >>>>>>>>>> increase monotonically if you use a YMD format :) > >>>>>>>>> > >>>>>>>>> I agree with Wayne that it's more meaningful than most version > >>>>>>>> strings. > >>>>>>>>> > >>>>>>>>> My understanding is that "integerized date" without punctuation is > >>>>>>>>> more commonly known as the "ISO 8601 date basic format". > >>>>>>>>> > >>>>>>>>> Recently I've been putting a date like that on the silkscreen of my > >>>>>>>>> PCBs. (I use the "ISO 8601 date extended format" like 2016-04-07, > >>>>>>>>> the > >>>>>>>>> format produced by the KiCad "%D" format symbol). > >>>>>>>>> > >>>>>>>>> Is it possible to combine that with Semantic versioning, getting > >>>>>>>>> something like 2016.04.07 ? > >>>>>>>>> (This assumes we won't make a breaking change in the file format > >>>>>>>>> more > >>>>>>>>> than once a year -- optimistic? :-) > >>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> David Cary > >>>>>>>>> +1(918)813-2279 > >>>>>>>>> http://OpenCircuits.com/ > >>>>>>>>> http://david.carybros.com/ > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> ------------------------------------------------------------------------ > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> Mailing list: https://launchpad.net/~kicad-developers > >>>>>>>> Post to : kicad-developers@lists.launchpad.net > >>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers > >>>>>>>> More help : https://help.launchpad.net/ListHelp > >>>>>>> > >>>>>>> -- > >>>>>>> Enviado desde mi dispositivo Android con K-9 Mail. Por favor disculpa > >>>>>>> mi brevedad. > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Mailing list: https://launchpad.net/~kicad-developers > >>>>>> Post to : kicad-developers@lists.launchpad.net > >>>>>> Unsubscribe : https://launchpad.net/~kicad-developers > >>>>>> More help : https://help.launchpad.net/ListHelp > >>>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Mailing list: https://launchpad.net/~kicad-developers > >>>>> Post to : kicad-developers@lists.launchpad.net > >>>>> Unsubscribe : https://launchpad.net/~kicad-developers > >>>>> More help : https://help.launchpad.net/ListHelp > >>> _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp