Decide what locked means in pcbnew and implement it uniformly

Bug #1745627 reported by Jeff Young
64
This bug affects 12 people
Affects Status Importance Assigned to Milestone
KiCad
Fix Released
Unknown

Bug Description

Different opinions exist about whether it should be "completely locked" or just "geometrically locked" or something else.

It also appears that even within those definitions that pcbnew isn't consistent.

See https://bugs.launchpad.net/kicad/+bug/1066220.

Tags: pcbnew
Jeff Young (jeyjey)
Changed in kicad:
status: New → Triaged
milestone: none → 6.0.0-rc1
importance: Undecided → Low
Revision history for this message
Jeff Young (jeyjey) wrote :

We also currently conflate locked with "footprint not from schematic". Good idea or bad?

Revision history for this message
Seth Hillbrand (sethh) wrote :

I think bad. Mostly because there are at least two user cases that directly conflict when a footprint doesn't exist on the schematic:

1) I add mounting holes as footprints and lock them. I don't want them moved or removed during an update.

2) I remove an element from the schematic. I _do_ want it removed during an update.

Revision history for this message
eelik (eelik) wrote :

(Copied and continued from another report)

The current "lock pads" prevents accidental moving by grabbing and dragging with mouse. It has always been enough for me. However, selecting pad vs. footprint is always a problem. There could be a dedicated "Don't allow selecting individual pads" choice. Then trying to select a pad would select the whole footprint. That would prevent accidental changing of pad properties and moving it with mouse. It would also ease the disambiguation of item selection. But moving the footprint by dragging would still be possible when the footprint itself is not locked.

Logically locking the placement of the footprint on the one hand and selecting a pad and editing pad properties on the other are two different things. That's why it's a bit weird now that they are bundled together (in the development version).

Even more fine grained locking would be useful. For example dragging a reference instead of footprint is a recurring annoyment. But that would be more useful as a global choice instead of per footprint.

The most versatile option would be to have global choices for certain locked things which could be overriden in each footprint.

So there could be global choices:
- Lock pad location to prevent moving with mouse (but not selection or changing properties)
- Lock pad selection (logically locks also properties, selects the footprint instead)
- Lock footprint text selection (selects the footprint instead)

These could be overriden in each footprint, at least for pads, and there would be also "Lock footprint location".

Revision history for this message
eelik (eelik) wrote :

I read the report thread linked to above. It seems "locking" isn't an easy word. To clarify a bit, there are at least three things which can be considered here:

- Prevent moving via dragging with mouse or keyboard arrows,
  or possible other WYSIWYG editing with mouse which can happen
  easily by accident
- Prevent changing properties
- Prevent individual selection (logically includes the two above)

Then there are different properties which people may want to be locked or not:
- Location: important to be able to lock
- Internal geometry (size, shape etc.)
- Zone connection of a pad: important to be able to changed
- Net of a pad, can't be even changed in the fp editor
- etc.

The "most versatile option" in the previous comment would need pcb/fp file format change. I think it would be possible to implement project settings which would be a good compromise:

- Prevent selecting individual pads (select the fp instead)
    * this would be effective globally unconditionally, or
      unless the individual footprint locking is "free"
    * this would logically prevent all property changes
    * currently locking a fp does this although they are
      conceptually different things
- Prevent selecting text items of footprints (select the fp instead)
    * currently there's no way to do that, even locked footprints
      let you select and move texts (which is often annoying)

These would be not selected by default, so there would be no change for the old users. Interpretation of the "Lock fp" option could be kept as it is or changed to "prevent moving the fp but allow selecting pads" (and renamed to "Lock fp position"?).

Preventing selection would make working with the board easier because it's more common that you want to select and move a footprint than to change or move a pad or text. The non-selectable items wouldn't be in the selection clarification menu. It would be relatively easy to change these options on/off when needed. Preventing selection would protect from all accidental or unwanted changes. Those who are nervous about fp changes can keep the option on and those who feel it would hinder them could keep it off. I would probably keep it mostly on and turn it off when I need to change something.

Revision history for this message
Jeff Young (jeyjey) wrote :

Bumping priority given how often this issue comes up.

Changed in kicad:
importance: Low → Medium
Revision history for this message
Rene Poeschl (poeschlr) wrote :

A have been made aware that my request [1] for a specialized flag only handling "this footprint has no symbol on purpose and should not be removed on update" could be related. I am however not certain if these two requests should be combined as i fear it might derail or at least balloon either request.

1: https://bugs.launchpad.net/kicad/+bug/1827002

Revision history for this message
Paul van der hoeven (paulvdh) wrote :

I like keeping things as simple as possible (but not simpler).

Having lots of different locks for different functions makes things more complicated then needed.

What if there is only one kind of lock, but there is a simple way to temporarily overrule it.
The goal is to never have automated tools touch locked parts, but when a user want to manually move, delete, edit a locked part it can do so after a warning, but the part keeps it's lock.

Recently I had a locked via for connection to a poer plane, and later wanted to manualy move it to a different position. KiCad(V5.2.0 warned me with "The selected item is locked" and asked for confirmation [Cancel] [Drag Anyway] I overruled it and dragged the via, but then it also lost its lock.

tags: added: pcbnew
Revision history for this message
rico (leesocir) wrote :

Footprint locking is primarily used for mechanical parts/constraineds (Location) by us.

Moving a component is fast and easy and it should be possible to disabled it for some parts e.g. connectors. Which is true rigth now, but i think the same "disable to move" action should be possible for polygons and outlines.

It is true that moving a single element does not happen by accident because you have to select the element itself before you can move, but this is not true for moving a greater selection of parts. If a group of elements is selected everything is moved at once at that is why lines and polygons should be also "lockable" in the same manner as footprints are.

The second thing why I would like to see "locking" would be because it happens some times that I try to delete a track or similar and accidentally delete the polygon in the background. If only the polygon outline is illustrated and it's outline is out of view no visual change happens but the polygon is removed.

Calling it Lock Location would be fine, except for the case that locked items are not removed by an update if deleted in the Schematic. But since this raises a clear error I could accept that. Locking of all other Properties seems unnecessary to me, but maybe someone can give an example.

Revision history for this message
KiCad Janitor (kicad-janitor) wrote :

KiCad bug tracker has moved to Gitlab. This report is now available here: https://gitlab.com/kicad/code/kicad/-/issues/1772

Changed in kicad:
status: Triaged → Expired
Changed in kicad:
importance: Medium → Unknown
status: Expired → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.