PCBNew does not update footprints after modification in the library

[Adam]

If you create a PCB project and import a netlist, you see the imported footprints.
Now, if you modify one of these footprints in the library from which it has been imported, and import the netlist again (having selected "Change" in "Exchange footprint"), PCBNew ignores the modifications and leaves the old footprint intact.

I attach an exemplary project illustrating the problem.
In the kicad_pcb file there is an incorrect MBGA100 footprint.
The kicad_mod file defining the footprint is the corrected version (some pads are removed).
I have modified the fp-lib-table, so that if you choose to add a new footprint you can select the corrected MBGA footprint.
However, updating the netlist has no effect on the footprint.

[Tomasz Wlostowski (twlostow)]

Hi Adam,

Try deleting the incorrect footprint from the PCB design and then updating the netlist.

Cheers,
Tom

[Nick Østergaard (nickoe)]

I have seen multiple persons report this, maybe this is a side effect of the recent cvpcb changes?

[Wayne Stambaugh (stambaughw)]

This is not due to the recent CvPcb changes. This has always been the
case. The only time the footprint gets changed on a netlist import is
when the FPID of the footprint has changed and the exchange footprint
option is selected in the netlist import dialog. If you modify a
footprint and do not change the FPID, you must open the "Footprint
Properites" dialog, click the "Change Footprint(s)" button, select
"Change Footprint" option in the "Exchange Footprints" dialog, and click
OK. This will reload the modified footprint from the same FPID.

On 6/19/2015 3:59 PM, Nick Østergaard wrote:
> I have seen multiple persons report this, maybe this is a side effect of
> the recent cvpcb changes?
>
> ** Tags added: netlist
>

[Adam (arudzins)]

If this is not a bug in the code itself, it is a "conceptual bug".

This should not be this way, if KiCad is intended to be a reliable CAD software.
So far you did an excellent job, please, don't waste it by neglecting such details.

1) The netlist import dialog clearly suggests, that after the update you'll have the updated footprints. Now it is misleading for the designer and can easily result in erroneous PCB design.

2) If a number of people cooperate sharing a footprint library, they shouldn't really have to ask if one of them has just corrected an incorrectly designed footprint.

3) If I work on 3-4 designs in parallel I will not remember to update the footprints in each of them.

If the "exchange" option is present, it should _always_ cause the update of the footprint.
Perhaps the footprint itself could be identified by a timestamp, similarly like symbols on the schematics can.
(BTW can this be made the default option?)
Optionally, the user could be warned that the footprint is to be updated and get the possibility too choose whether to keep the old version (something like the footprint assignment called from eeschema did if the footprint in the cmp file did not match the value in the netlist file).

[Wayne Stambaugh (stambaughw)]

The exchange option only applies if the FPID has changed since the last
netlist import. It does not apply to differences between the footprint
in a library and the footprint on the board. By design, footprints are
embedded in the board file so they can be modified in place. I
absolutely do not want anything automatically changing my footprints in
a board after I've completed a layout unless I specifically request
changing them myself. When the netlist is read in Pcbnew, it does not
(and cannot) know if the footprint in the library has change or you have
edited the footprint on board in place. How would you even check this
in a sane manner? If I compare the every footprint embedded in a board
file against it's library version by FPID, what changes do I test for to
trigger an exchange? For example, I always change the reference silk
screen sizes because my boards are very small. None of my footprints
would match the library version even if the library version didn't
change. What about solder mask clearances, solder paste clearances,
thermal relief settings, etc., etc. These are just some of the things I
change on a per footprint basis in my board designs. I think trying to
automatically change modified library footprints on a board is opening
up one seriously ugly can of worms.

On 6/19/2015 4:41 PM, Adam wrote:
> If this is not a bug in the code itself, it is a "conceptual bug".
>
> This should not be this way, if KiCad is intended to be a reliable CAD software.
> So far you did an excellent job, please, don't waste it by neglecting such details.
>
> 1) The netlist import dialog clearly suggests, that after the update
> you'll have the updated footprints. Now it is misleading for the
> designer and can easily result in erroneous PCB design.
>
> 2) If a number of people cooperate sharing a footprint library, they
> shouldn't really have to ask if one of them has just corrected an
> incorrectly designed footprint.
>
> 3) If I work on 3-4 designs in parallel I will not remember to update
> the footprints in each of them.
>
> If the "exchange" option is present, it should _always_ cause the update of the footprint.
> Perhaps the footprint itself could be identified by a timestamp, similarly like symbols on the schematics can.
> (BTW can this be made the default option?)
> Optionally, the user could be warned that the footprint is to be updated and get the possibility too choose whether to keep the old version (something like the footprint assignment called from eeschema did if the footprint in the cmp file did not match the value in the netlist file).
>

[Adam (arudzins)]

You _do_ want to change a footprint if you have used an incorrectly designed one.
You should at least get a notification of the modification and have the option to use the new footprint.

Everything that is defined as a constant feature of the footprint should be compared.
This includes: pads, lines, texts, predefined solder mask clearance, 3D model, etc.
I think that only parametrized texts (those defined on the schematics) should be excluded.
In other words: those which identify the component (designators) on the PCB or assembly
drawing (here also the name of the footprint and its value), as well as any user-defined texts.

Perhaps the FPID could contain a "magic number" calculated based on the compared elements.
Like a CRC calculated for the file, having discarded the "volatile" features.

If it is desired to prevent updating a particular footprint, in my opinion it is better to explicitly "lock"
the footprint, just like you can do to prevent changing its position.

BTW it would be nice to have the "update footprint from library" option in the right-click context menu.
(or did I give up searching too easily?)

[Wayne Stambaugh (stambaughw)]

On 6/19/2015 6:11 PM, Adam wrote:
> You _do_ want to change a footprint if you have used an incorrectly designed one.
> You should at least get a notification of the modification and have the option to use the new footprint.

How do you define an "incorrectly" designed footprint? I'm constantly
tweaking "correctly" designed footprints to improve design layout and
ease of manufacturing. How do you know when a footprint is changed that
it actually corrected anything that would cause manufacturing issues? I
could be something as insignificant and changing the silk screen
thickness. Do we really want something like this to trigger a warning
(nag ware) every time there is a change?

>
> Everything that is defined as a constant feature of the footprint should be compared.
> This includes: pads, lines, texts, predefined solder mask clearance, 3D model, etc.
> I think that only parametrized texts (those defined on the schematics) should be excluded.
> In other words: those which identify the component (designators) on the PCB or assembly
> drawing (here also the name of the footprint and its value), as well as any user-defined texts.

These constants are not constant. It is not (at least for me) uncommon
to make local modifications to one or more pads or silk screen graphics
for design and manufacturing specific purposes.

>
> Perhaps the FPID could contain a "magic number" calculated based on the compared elements.
> Like a CRC calculated for the file, having discarded the "volatile" features.

This would be only way I know to do this and it would require a change
in the board file format. This would not happen until after the
upcoming stable release.

>
> If it is desired to prevent updating a particular footprint, in my opinion it is better to explicitly "lock"
> the footprint, just like you can do to prevent changing its position.
>
> BTW it would be nice to have the "update footprint from library" option in the right-click context menu.
> (or did I give up searching too easily?)
>

There is no context menu entry for this feature but I doubt it would be
terribly difficult to add to the footprint sub-menu.

[Adam (arudzins)]

"Incorrect" could mean that, for example, the pads have been drawn in wrong positions, they've been too short or that somebody forgot to add specific pastemask definition. You want to know that this has been corrected.

This is something different than intended "customization", of course, everything is up to the designer and it's very good if the CAD allows to change all the things at will.

OK, both approaches have their pros and cons.

So, the very fundamental problem is that the netlist import dialog is not precisely telling what will happen. My suggestion is then to add a third choice to "Exchange footprint". The selection could be
- keep;
- exchange if completely different footprint (name differs);
- update any footprint modifications (load/replace by current version from the library).
If still needed, the aforementioned "magic number" could be calculated on-the-fly only in the third case.

[joe schoelen (eedude)]

Q: How do we get an existing PCB design to respect updated footprints in the library?

I'm in the same boat as Adam. I expected my footprints to be updated from the library since Exchange Footprint is checked. The checkbox implies that I will get the fresh footprint from the lib. I'm wasting so much time on what should be a simple process.

"Try deleting the incorrect footprint from the PCB design and then updating the netlist."
How? Del them off the board and replace, or is there a del footprint in the PCB? Deleting off the board and replace is not a solution.

FPID
Where is FPID, I looked in footprint editor and could not find such a field in Edit -> Edit Properties.

[Robert Baruch (robertbaruch)]

I'm in the same boat, too. I noticed that the 3D model on one footprint had the component on its side, so I updated it in my library. But there's no way to get that change to the 100 instances of that footprint on my PCB unless I delete every single one of them, reimport them and place them again? All 100 of them? That doesn't seem like a good workflow to me.

[Robert Baruch (robertbaruch)]

Here's what I think should happen. Here's the footprint mentioned in the .kicad_pcb file:

  (module quad_level_shifter:SOD-882L (layer F.Cu) (tedit 5843C2EE) (tstamp 58449627)
    (at 121.412 82.804 270)
    (path /584465CE)
    (fp_text reference D1 (at -1.524 0 270) (layer F.SilkS)
      (effects (font (size 0.5 0.5) (thickness 0.1)))
    )
    (fp_text value CFSH05-20L (at 0.1 -1.8 270) (layer F.Fab) hide
      (effects (font (size 0.5 0.5) (thickness 0.125)))
    )
    (fp_line (start -0.5 -0.5) (end -0.5 0.5) (layer F.Fab) (width 0.1))
    (fp_text user REF** (at 0.6 0 270) (layer F.Fab)
      (effects (font (size 0.5 0.5) (thickness 0.1)))
    )
    (fp_line (start -0.9 -0.5) (end -0.9 0.5) (layer F.Fab) (width 0.1))
    (fp_line (start 0.9 0.5) (end 0.9 -0.5) (layer F.Fab) (width 0.1))
    (fp_line (start -0.9 0.5) (end 0.9 0.5) (layer F.Fab) (width 0.1))
    (fp_line (start 0.9 -0.5) (end -0.9 -0.5) (layer F.Fab) (width 0.1))
    (fp_line (start -0.5 -0.5) (end 0.9 -0.5) (layer F.SilkS) (width 0.1))
    (fp_line (start -0.9 0.5) (end -0.9 -0.5) (layer F.SilkS) (width 0.1))
    (fp_line (start 0.9 0.5) (end -0.5 0.5) (layer F.SilkS) (width 0.1))
    (fp_line (start 0.9 -0.5) (end 0.9 0.5) (layer F.SilkS) (width 0.1))
    (pad 1 smd rect (at -0.4 0 270) (size 0.55 0.6) (layers F.Cu F.Paste F.Mask)
      (net 1 +12V))
    (pad 2 smd rect (at 0.4 0 270) (size 0.55 0.6) (layers F.Cu F.Paste F.Mask)
      (net 4 /IO0_HV_DR))
    (model "F:/KiCad Projects/QuadLevelShifter/3D/SOD-882.wrl"
      (at (xyz 0 0 0))
      (scale (xyz 0.39 0.39 0.39))
      (rotate (xyz 0 0 0))
    )
  )

And now here is my updated footprint, the .kicad_mod file:

(module SOD-882L (layer F.Cu) (tedit 5844A2EF)
  (fp_text reference REF** (at 0 1.27) (layer F.SilkS)
    (effects (font (size 0.5 0.5) (thickness 0.1)))
  )
  (fp_text value CFSH05-20L (at 0 -1.27) (layer F.Fab) hide
    (effects (font (size 0.5 0.5) (thickness 0.125)))
  )
  (fp_line (start -0.5 -0.5) (end -0.5 0.5) (layer F.Fab) (width 0.1))
  (fp_text user REF** (at 0.6 0) (layer F.Fab)
    (effects (font (size 0.5 0.5) (thickness 0.1)))
  )
  (fp_line (start -0.9 -0.5) (end -0.9 0.5) (layer F.Fab) (width 0.1))
  (fp_line (start 0.9 0.5) (end 0.9 -0.5) (layer F.Fab) (width 0.1))
  (fp_line (start -0.9 0.5) (end 0.9 0.5) (layer F.Fab) (width 0.1))
  (fp_line (start 0.9 -0.5) (end -0.9 -0.5) (layer F.Fab) (width 0.1))
  (fp_line (start -0.5 -0.5) (end 0.9 -0.5) (layer F.SilkS) (width 0.1))
  (fp_line (start -0.9 0.5) (end -0.9 -0.5) (layer F.SilkS) (width 0.1))
  (fp_line (start 0.9 0.5) (end -0.5 0.5) (layer F.SilkS) (width 0.1))
  (fp_line (start 0.9 -0.5) (end 0.9 0.5) (layer F.SilkS) (width 0.1))
  (pad 1 smd rect (at -0.4 0) (size 0.55 0.6) (layers F.Cu F.Paste F.Mask))
  (pad 2 smd rect (at 0.4 0) (size 0.55 0.6) (layers F.Cu F.Paste F.Mask))
  (model "F:/KiCad Projects/QuadLevelShifter/3D/SOD-882.wrl"
    (at (xyz 0 0 0))
    (scale (xyz 0.39 0.39 0.39))
    (rotate (xyz -90 0 0))
  )
)

Note that tedit has changed, and so has the rotate element.

Now, when I go into my PCB, I expect to be able to change the options so that I replace the footprint in the kicad_pcb file with the one in the kicad_...

[Chris Gray (chgray)]

Thanks for all the commenting and theory, I'm new to KiCAD and cant parse what to do to get the footprint to reload?

it'd be much appreciated if someone would dumb this down a little to help me grock whats going on :) (read: what do I click :))

[Nick Østergaard (nickoe)]

You can just make it replace it when importing the netlist from eeschema.

[Adam (arudzins)]

Right click the footprint, there's an option to update.

You can choose to update a single footprint or all the footprints of the
same type.

This reloads the current definition of the footprint.

On 01/15/2017 09:16 PM, Chris Gray wrote:
> Thanks for all the commenting and theory, I'm new to KiCAD and cant
> parse what to do to get the footprint to reload?
>
> it'd be much appreciated if someone would dumb this down a little to
> help me grock whats going on :) (read: what do I click :))
>

[Chris Gray (chgray)]

Adam, thanks for the info - I'm making boards in kicad, but I wouldnt say I'm *good* at using the tool. I dont fully grock the work flow (where data is copied, and where it's used via indirection)

From which tool do I right click footprint? (from the pcbnew?)

[Adam (arudzins)]

Yes, that's available in pcbnew. The option is called "Exchange footprint(s)".
It's located in context menu for a footprint - you need to right click
on the one you want to update.

On Sun, Feb 12, 2017 at 6:58 PM, Chris Gray <email address hidden> wrote:
> Adam, thanks for the info - I'm making boards in kicad, but I wouldnt
> say I'm *good* at using the tool. I dont fully grock the work flow
> (where data is copied, and where it's used via indirection)
>
> >From which tool do I right click footprint? (from the pcbnew?)
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1466857
>
> Title:
> PCBNew does not update footprints after modification in the library
>
> Status in KiCad:
> Invalid
>
> Bug description:
> If you create a PCB project and import a netlist, you see the imported footprints.
> Now, if you modify one of these footprints in the library from which it has been imported, and import the netlist again (having selected "Change" in "Exchange footprint"), PCBNew ignores the modifications and leaves the old footprint intact.
>
> I attach an exemplary project illustrating the problem.
> In the kicad_pcb file there is an incorrect MBGA100 footprint.
> The kicad_mod file defining the footprint is the corrected version (some pads are removed).
> I have modified the fp-lib-table, so that if you choose to add a new footprint you can select the corrected MBGA footprint.
> However, updating the netlist has no effect on the footprint.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/kicad/+bug/1466857/+subscriptions

[stevegt (stevegt)]

Guys, I'm sorry, but this is a bug, not a feature. I just now wasted a couple of hours trying to get an array of footprints to update -- it got to the point where I thought I was losing my mind. Extremely frustrating experience. Not a good idea to force people into that bad user experience, not a good idea to expect them to manually manipulate each footprint in a large array of identical footprints, and not a good idea to close as invalid the valid observations of new users and potential developers who bring a fresh perspective.

Think of the value of having a single source of truth: What you're doing right now is encouraging people to futz with footprints in the board, rather than going back and fixing them in the library in the first place. That's just encouraging bad habits, and those bad habits are now encouraging the retention of a bug in an otherwise good tool.

If the upstream library you're using is third-party and you don't like the silkscreen, then *fix the silkscreen* and save it in a local library where you or others can benefit from it later on; don't keep repeating the same work by fixing up footprints in the board.

Editing footprints after they've been embedded in a board is directly equivalent to editing binaries after they've been compiled, or editing gcode or a gerber file by hand after it's been generated. This creates irreproducible results, and lays a trap for someone to fall into later, and it might be you. It's bad practice, pure and simple.

Kicad has great promise -- please don't cripple it by making it safe for amateurs but clumsy for professionals.

If you're concerned about existing behavior changing, then add a third radio button on the netlist dialog that says "yes, really, please exchange all footprints even if their FPID hasn't changed, I mean it". If you don't have time to make this code change yourself, then please at least leave the bug open so that someone who does have the time and cares about the problem will go to the effort of making the code change with some hope of it being accepted.

Rant over, but I hope I'm making sense. Thanks all.

[stevegt (stevegt)]

For anyone else who stumbles across this bug -- I made an error in my first paragraph above: In the case of identical footprints, if you right-click on the footprint in pcbnew and select "Exchange Footprints, you'll get a dialog box that gives you a few options for changing identical footprints based on name or value.

There's also an option there named "Update all footprints of the board" -- I'm not sure what that does. Is that the functionality I'm wishing for in the last paragraph of #18 above? If so, why oh why is it buried in there? The thing that people do often, if they're following good practice, is update the board from the netlist. That radio button I'm describing in #18 needs to be right there on the netlist update dialog, where people can see it and not have to add more comments to this already lengthy bug.

[Nick Østergaard (nickoe)]

Yes, I think that is what you are looking for. Please keep in mind we can only use constructive and precise criticism, avoid fluffy ranting.

There are workflows that can be improved. It is more useful, includimg some more advanced way of updating footprints.

[Adam (arudzins)]

I've just had a thought, that maybe instead of storing modified footprints as such a PCB should rather store patches to used library components. That's just an idea, no details behind it.
This way, if a "minor" correction is done in the library, you might both get an update on the PCB and keep your modifications. If "major" corrections are done, a patch will probably fail, but in this case probably you want to have a closer look at that anyway.

[stevegt (stevegt)]

I understand, Nick, and thank you. As constructive and precise as I can get it:

Plan A: Add an "Update all footprints" radio button to the "Read netlist" dialog box, in the "Exchange footprint" radio group. Rename the existing "Change" button to "Update footprint if FPID changed". I'd be open to other language, but the key is to make it clear to the user that FPID is a trigger, and to give them the option of updating all footprints regardless of FPID.

Plan B: Don't change the buttons, just fix the tooltip. Good wording for the tooltip would be "Keep or change an existing footprint if footprint ID has changed in netlist". Right now the tooltip doesn't mention FPID at all: "Keep or change an existing footprint when the netlist gives a different footprint". That implies that regenerating the netlist will cause footprint replacement if the footprints have in some way changed, and is helping to generate comments on this bug report.

I'd be happy to submit a patch, but don't want to spend time on this if the consensus is not there. If this bug remains in "Confirmed" status this time, I'll take that as a signal that there is consensus for a change. If nobody else takes it first, I'll assign the bug to myself and submit a patch.

Thanks again all.

[Wayne Stambaugh (stambaughw)]

On 10/21/2017 4:55 PM, stevegt wrote:
> I understand, Nick, and thank you. As constructive and precise as I can
> get it:
>
> Plan A: Add an "Update all footprints" radio button to the "Read
> netlist" dialog box, in the "Exchange footprint" radio group. Rename the
> existing "Change" button to "Update footprint if FPID changed". I'd be
> open to other language, but the key is to make it clear to the user that
> FPID is a trigger, and to give them the option of updating all
> footprints regardless of FPID.

Please avoid using code names like FPID in UI strings. Most users are
not going to know what an FPID is. A better string might be "Update
footprint if change in schematic". I some respects "Update footprint"
may be adequate given that the netlist generated by the schematic is
being imported which has nothing to do with changing a footprint in a
library.

>
> Plan B: Don't change the buttons, just fix the tooltip. Good wording for
> the tooltip would be "Keep or change an existing footprint if footprint
> ID has changed in netlist". Right now the tooltip doesn't mention FPID
> at all: "Keep or change an existing footprint when the netlist gives a
> different footprint". That implies that regenerating the netlist will
> cause footprint replacement if the footprints have in some way changed,
> and is helping to generate comments on this bug report.

I would change both the radio button string and the tooltip string to
make it as clear as possible.

>
> I'd be happy to submit a patch, but don't want to spend time on this if
> the consensus is not there. If this bug remains in "Confirmed" status
> this time, I'll take that as a signal that there is consensus for a
> change. If nobody else takes it first, I'll assign the bug to myself and
> submit a patch.
>
> Thanks again all.
>

[Jeff Young (jeyjey)]

I see two bugs here:

1) The option in Read Netlist is confusing. There are already suggestions for fixing this.

2) The global option is buried where it isn't often found. We already have 5 global editing operations on the Edit menu; moving this one there would make it easily found.

(I would also suggest *removing* it from the Change Footprint dialog as it's confusing there.)

[Anders Olsson (angu)]

> If you modify a
> footprint and do not change the FPID, you must open the "Footprint
> Properites" dialog, click the "Change Footprint(s)" button, select
> "Change Footprint" option in the "Exchange Footprints" dialog, and click
> OK. This will reload the modified footprint from the same FPID.

And then it replies "No" which isn't very helpful. It worked in previous versions.
I have no idea what a FPID is or how to change it and I don't think I should need to know.

Kicad is a very powerful software and there are different opinions regarding bugs/features but if it can't be used by a regular user, I consider it a bug.

[jean-pierre charras (jp-charras)]

If the reply is "No", the "new" footprint is just no found (FPID no found in any loaded fp library).
I don't think this is a bug.

[Anders Olsson (angu)]

OK, my project is pulled from subversion so maybe the problem in my case is with project settings (although the library is present in Preferences -> Footprint Libraries Manager and I just edited the footprint).

I do agree with what's been said before, that there is often a need to modify a footprint on the board without changing it in the library. So I prefer to use the "Exchange Footprints" dialog instead of having everything done automatically when I import the netlist.

However I think there are a few good points in this discussion. It would be helpful with a tooltip for "Update all footprints of the board" so that the user knows exactly what the effect of this option is. I use kicad professionally for rather complicated layouts and have evaluated a number of software suites. They all take a lot of getting used to since all people have different opinions about how the software "should work". I prefer to use kicad, but I would like to see more tooltips, explanations etc. That would make it easier for users to figure out how to do things, rather than asking for help. And I still think that "no" is not a helpful message.

[Jeff Young (jeyjey)]

@Wayne, not sure whether you had 5 or 6 in mind for this one, but attached is a patch if you want to take a look at it.

Simplify Exchange Footprints dialog and add Update mode.

This commit also adds a no-selection-mode, which allows the user
to specify what gets update (through the various match modes).
The no-selection-mode is accessed via the Edit menu, although
it could also be applied to the context menu.

[Wayne Stambaugh (stambaughw)]

@Jeff, your patch no longer applies cleanly. Please rebase and resubmit
it so I can apply and test it. Thanks.

On 1/12/2018 5:03 PM, Jeff Young wrote:
> @Wayne, not sure whether you had 5 or 6 in mind for this one, but
> attached is a patch if you want to take a look at it.
>
> Simplify Exchange Footprints dialog and add Update mode.
>
> This commit also adds a no-selection-mode, which allows the user
> to specify what gets update (through the various match modes).
> The no-selection-mode is accessed via the Edit menu, although
> it could also be applied to the context menu.
>
>
> ** Patch added: "0004-Simplify-Exchange-Footprints-dialog-and-add-Update-m.patch"
> https://bugs.launchpad.net/kicad/+bug/1466857/+attachment/5035962/+files/0004-Simplify-Exchange-Footprints-dialog-and-add-Update-m.patch
>

[Jeff Young (jeyjey)]

Patch rebased.

[Wayne Stambaugh (stambaughw)]

@Jeff, this patch:

On 1/17/2018 10:37 AM, Jeff Young wrote:
> Patch rebased.
>
> ** Patch added: "0002-Keep-value-footprint-and-datasheet-in-sync-in-multi-.patch"
> https://bugs.launchpad.net/kicad/+bug/1466857/+attachment/5038295/+files/0002-Keep-value-footprint-and-datasheet-in-sync-in-multi-.patch
>

[Wayne Stambaugh (stambaughw)]

Try this again. I meant this patch:

https://bugs.launchpad.net/kicad/+bug/1466857/+attachment/5035962/+files/0004-Simplify-Exchange-Footprints-dialog-and-add-Update-m.patch

On 1/17/2018 10:37 AM, Jeff Young wrote:
> Patch rebased.
>
> ** Patch added: "0002-Keep-value-footprint-and-datasheet-in-sync-in-multi-.patch"
> https://bugs.launchpad.net/kicad/+bug/1466857/+attachment/5038295/+files/0002-Keep-value-footprint-and-datasheet-in-sync-in-multi-.patch
>

[Jeff Young (jeyjey)]

Ooops. That one has merge conflicts. I'll upload it once I've sorted those and tested it again.

[Jeff Young (jeyjey)]

Rebased patch uploaded.

[Jeff Young (jeyjey)]

Note that this patch may or may not qualify for v5. I think it's a big usability improvement, but it's also a big change.

[Wayne Stambaugh (stambaughw)]

I will try to find the time to take a look at this over the weekend and
make a decision.

On 1/17/2018 1:31 PM, Jeff Young wrote:
> Note that this patch may or may not qualify for v5. I think it's a big
> usability improvement, but it's also a big change.
>

[Jeff Young (jeyjey)]

@Wayne, did you have a chance to look at this?

[Wayne Stambaugh (stambaughw)]

Not yet. I was traveling over the weekend and just didn't get to it.
I'm going to try to get to it this week as I want to branch rc1 this
weekend if possible.

On 01/22/2018 05:34 PM, Jeff Young wrote:
> @Wayne, did you have a chance to look at this?
>

[Wayne Stambaugh (stambaughw)]

@Jeff, I hate to ask you again but this patch no longer applies cleanly.
 Please rebase it again. I will do my best to review it as soon as
possible. Thanks.

On 1/17/2018 1:30 PM, Jeff Young wrote:
> Rebased patch uploaded.
>
> ** Patch added: "0004-Simplify-Exchange-Footprints-dialog-and-add-Update-m.patch"
> https://bugs.launchpad.net/kicad/+bug/1466857/+attachment/5038376/+files/0004-Simplify-Exchange-Footprints-dialog-and-add-Update-m.patch
>

[Jeff Young (jeyjey)]

@Wayne, rebased patch attached.

[Jeff Young (jeyjey)]

Hmmm... *actually* attached this time.

[Wayne Stambaugh (stambaughw)]

It looks like we still have some issues to resolve before the v5 branch so I merged your patch. I am going to ask you to please take a look at the layout of the text edit controls in the dialog when they are shown. It would be nice to have them aligned using a grid spacer rather than spaced just to the right of the radio button text. Also, please do not set control states in command event handlers. Use wxUpdateUIEvent for this. It makes for cleaner code and you don't have to worry about setting the control states in every event handler and risk getting them wrong. These fixes can be a separate patch. Thanks.

[KiCad Janitor (kicad-janitor)]

Fixed in revision 4c29ab6c09d027ff55714d2b4f5db3884fef13cf
https://git.launchpad.net/kicad/patch/?id=4c29ab6c09d027ff55714d2b4f5db3884fef13cf

[Jeff Young (jeyjey)]

@Wayne, patch attached with requested fixes (and a correction to the icon).

[Wayne Stambaugh (stambaughw)]

@Jeff, your 0004 patch did not apply cleanly. Please rebase it when you get a chance so I get it merged. Thanks!

[Jeff Young (jeyjey)]

That was from my messed-up branch, so I just re-created it from cherry-picked files.

[Jeff Young (jeyjey)]

@Wayne, just checking in to see if you had a chance to merge this yet....

[Wayne Stambaugh (stambaughw)]

@Jeff, thanks for the reminder. I just merged this patch.

On 1/30/2018 4:17 PM, Jeff Young wrote:
> @Wayne, just checking in to see if you had a chance to merge this
> yet....
>

[KiCad Janitor (kicad-janitor)]

Fixed in revision 53a05f18e15008e98bd97015a501ccfe35a80893
https://git.launchpad.net/kicad/patch/?id=53a05f18e15008e98bd97015a501ccfe35a80893