[Feature request] pcbnew: PCB update from schematic -> Exclude locked footprints

Description

It would be good to have another option in the PCB update from schematic dialog. If the option "Replace footprints with ..." is selected, another option becomes visible and selectable "Exclude locked footprints from update". These components should then only generate a log warning or info, but not be updated if the new option is active.

There are always very good reasons why a footprint has been locked after placement. In most cases, it may not be moved or replaced.

KiCad Version

Application: KiCad x86_64 on x86_64Version: 7.0.9-1.fc39, release build

Libraries:
   wxWidgets 3.2.4
   FreeType 2.13.1
   HarfBuzz 8.2.1
   FontConfig 2.14.2
   libcurl/8.2.1 OpenSSL/3.1.1 zlib/1.2.13 libidn2/2.3.4 nghttp2/1.55.1Platform: Fedora Linux 39 (Workstation Edition), 64 bit, Little endian, wxGTK, gnome, x11

Build Info:
   Date: Nov  5 2023 00:00:00
   wxWidgets: 3.2.2 (wchar_t,wx containers) GTK+ 3.24
   Boost: 1.81.0
   OCC: 7.6.3
   Curl: 8.2.1
   ngspice: 41
   Compiler: GCC 13.2.1 with C++ ABI 1018

Build settings:
   KICAD_SPICE=ON

added 7.0 priorityundecided statusnew labels

changed title from [Feature request] pcbnew: PCB update from schematic to [Feature request] pcbnew: PCB update from schematic -> Exclude locked footprints

@kicad/code/lead_devs we currently refuse to remove a locked footprint, but we will update it. There's (currently) no user control over this.

We could:

a) leave it as-is

b) also refuse to update locked footprints

c) also refuse to update locked footprints and add a checkbox which controls updating

d) also refuse to update locked footprints and add a checkbox which controls both

e) also refuse to update locked footprints and add a checkbox for each

At some point we want to move to fine-grained control, so I'd slightly favour (a) or (b) to prevent wasted effort. But it could be a while before we implement fine-grained control, so

Did we ever come to a consensus for what "locked" means. To me it means, "don't make any changes to this object under any circumstances unless I unlock it". I memory serves, there are some folks who prefer lock to mean "don't move from this position but all other changes are okay". I think once we define what "locked" means, the answer will be obvious.

I prefer that locked means "don't let me select this interactively" but since we already have extended it to mean "don't allow deleting this" we are kind of stuck I think.

Which is fine if that is how we are going to define "locked". We need to put a stake in the ground so that going forward, we don't have a shifting definition which is what got us into this problem to begin with.

I think we need two different features. In my opinion "Locked" should be for controlling an object's select-ability to interact with it with the interactive tools, and should have nothing to do with controlling the behavior of batch-processing tools (such as Update from Schematic or Update from Libraries)

But we do need a way to prevent footprints from being messed with in the batch tools, and we don't have the time to create what I think is the right system, which is a GUI that lets you review and accept/reject changes.

So, because we can't have the thing that I think would be better, I don't think we can make there be no way to prevent batch editing functions from acting on a certain footprint. Therefore I think we basically have to do Jeff's (D) -- in every batch editing workflow, there should be a checkbox that controls whether or not locked footprints are affected. This checkbox will need to persist even if we make the better GUI in the future.

I don't think we need multiple checkboxes per dialog (separate checkboxes controlling removal vs updating in this particular example). The concept can just be "locked footprints are unaffected by any batch editing operation, but there's always a checkbox to make them be affected".

Last time around the general locking discussion we decided two things:

1. That locked meant "don't let me accidentally do interactive operations on this", but that explicit changes (properties dialogs, global editors, etc.) were OK.

2. That we wanted multi-level locking on at least tracks and vias so that we could do other types of locking.

We logged #7069 for (2).

Putting my comment another way: I don't think we should define locked to mean "not affected by batch processing", but because we need a way to let the user specify that some items should not be affected by batch processing, we at least temporarily should make sure that the batch processing workflows support at least one filter. The "is the locked flag set on this item" test is a reasonable filter that requires very little work to implement.

So, I'm not proposing that we expand the definition of "locked"; I'm proposing that we allow explicit filtering by "is this locked" in some places as a stand-in for a more advanced system.

(Note that said discussion was before we had the selection filter.)

Just for completeness I should mention that we implement a nag dialog on a bunch of interactive operations, which allows you to override locks. So we could do that on Update from Schematic, but I'm guessing that would get annoying real quick....

This override lock checkbox makes sense to me in the batch operation dialogs. I would avoid nag dialogs on batch operations. That would get old really quickly.

Hmm... the trouble with a single checkbox is there's no way to make it do what 6.0 did. Maybe that's OK, but it's giving me a little heart-burn....

It seems OK to me. Maintaining the behavior of "locked items can be changed but not removed" doesn't seem like something we need.

For future reference, the definition of "locked" from a tooltip:

"Locked footprints cannot be freely moved and oriented on the canvas and can only be selected when the 'Locked items' checkbox is checked in the selection filter."

So if I've followed the discussion correctly, it's not a new feature but just an extension and visualization of an undocumented feature?

What do you think of the suggestion that we should proceed in 2 steps?

Step 1: Implement 2 checkboxes like this and leave the default as it is. Kicad 9?

And extend the Update from Library dialog to an exclude checkbox. That completes it.

Step 2: Think about a multi-level locking concept that maybe already starts in the library for V9 or V10. Where you can already define locks in the components for values, attributes and footprints.

That's essentially it, though Jon didn't think we needed separate checkboxes so I went with one:

For Step 2, I think we're leaning more towards showing the user all the Update-from-Schematic changes and letting them pick which ones they want to apply.

This is also an elegant solution that appeals.

For Step 2, I think we're leaning more towards showing

Do you mean a solution comparable to the Altium difference comparator?

https://www.altium.com/documentation/altium-designer/keeping-schematics-pcb-synchronized#!configuring-the-eco-generation-options

I suspect so. @craftyjon makes reference to Altium in the issue we're using to track it (#7272), but I'm not an Altium user myself so I'm not 100% sure.

The workflow should be in some ways similar to Altium, but KiCad's UI will likely differ (Altium's is overcomplicated in my opinion)

That was not to be understood literally either. It was more of an idea of the direction it could take.

changed milestone to %9.0

assigned to @jeffyoung

added statusin-progress label and removed statusnew label

mentioned in commit jeffyoung/kicad@409d424a

added statusready-to-merge label and removed statusin-progress label

closed with commit 4c5dbcd7