pcbnew: disable locked items in selection clarification list

Bug #1066220 reported by Martin Errenst on 2012-10-13
40
This bug affects 7 people
Affects Status Importance Assigned to Milestone
KiCad
Low
Jeff Young

Bug Description

Problem: some items on the board are locked (like footprints). Trying to move those, will result in an popup telling you it's a locked part (which is fine).
If one tries to move those parts via the hotkey, imho, nothing should happen (actual result: the mentioned popup, slowing down the workflow).
If there's more then one part under the cursor, the "Selection Clarification" dialogue pops up (also ok), but locked items are selectable to move (which will result in the first mentioned popup).

An easy option to avoid selecting items which are locked, is to disable those entries in the list.
Sadly it's not possible to get any information inside the PCB_BASE_FRAME::PcbGeneralLocateAndDisplay ( int aHotKeyCode ) method (passing any argument to it will result in a segfault, also there's not a single place in the code, passing anything to it).
The main problem with the attached (ugly) quickfix to disable the locked entries is, you cannot tell what kind of action called the function (move, rotate and flip are forbidden for locked parts, but editing the properties for the part is ok - so one can disable the lock again).

The patch disables the "first level access" to the part, but selecting a pad from the part and then choosing the part from the pads menu still works. I don't really recommend using the patch ;).

Also it would be nice to number the entries inside the selection clarification menu (or all the other menus you can trigger with hotkeys) and assign some kind of context sensitive hotkeys, to access the right entry (like pressing '1' for the first entry and so on).

Version:
testing, 3762.

Evan Shultz (evan-shultz) wrote :

I'm also stumped by this. It seems to me that "fully locking" a part shouldn't allow it to be moved. How else can the designer feel safe that an electromechanical interface, such as a connector, won't accidentally get shifted even when the component is locked?

I've attached an example video of Cadence Allegro PCB Designer. You can see that the option to move the part goes away for an individual footprint, and when moving a group of footprints the locked/fixed part is de-selected and doesn't move. While the notification is arguably too minimal, at least it doesn't get too "in your face" like a blocking dialog and it's relatively easy to get used to.

Chris Pavlina (pavlina-chris) wrote :

I'm going to voice my agreement here. Handling of locked parts in pcbnew is pretty terrible - they're too easy to move, and they get in the way when working around them.

Changed in kicad:
status: New → Confirmed
Wayne Stambaugh (stambaughw) wrote :

+1. Locked means an object cannot be edited until it is unlocked. The only operation that should be allowed on a locked object is to unlock it. I believe this behavior is broken in both canvases.

Novak Tamas (novak-7) wrote :

@Wayne I see your logic, but I disagree. Locking a footprint is only a reminder for myself that its placement is fine and somehow important: not to accidently move that part. Still I often move these parts, and always doing a unlock / move / re-lock sequence was annoying.

When a single locked part is to be moved, the actual message is fine.

When multiple locked parts are concerned (members of a block to be moved), a list of locked parts with individual checkboxes would be the best.

@Chris you are right...E.g. I myself filed report #1576655 where locked FP could be moved without warning.

Then pick a different word than locked. Locked in English has a pretty
clear meaning and doing anything else will just confuse native English
speakers. Maybe you are looking for an "ignore on block move" status
which is different than locked.

On 8/6/2016 9:20 AM, Novak Tamas wrote:
> @Wayne I see your logic, but I disagree. Locking a footprint is only a
> reminder for myself that its placement is fine and somehow important:
> not to accidently move that part. Still I often move these parts, and
> always doing a unlock / move / re-lock sequence was annoying.
>
> When a single locked part is to be moved, the actual message is fine.
>
> When multiple locked parts are concerned (members of a block to be
> moved), a list of locked parts with individual checkboxes would be the
> best.
>
> @Chris you are right...E.g. I myself filed report #1576655 where locked
> FP could be moved without warning.
>

Well, even for an English speaker, locking a footprint needs to be defined.
I am (obviously) not an English speaker, but I am thinking a locked footprint cannot be moved, rotated, flipped or deleted (at least without prompting the user).
I could call these changes "geometrical changes" or "topological changes".

However it can be (partially) edited:
Fields(ref, value) can be moved/edited.
Netlist can be updated.
Netlist can change the footprint (but not delete it, because it can be added outside the netlist, for instance mechanical holes).

The issue is just the user is not always asked for these geometrical changes.

Novak Tamas (novak-7) wrote :

The mother language of 90% of mankind is not English. You should make it easier to use KiCad for them (with at most mid-quality English) using simple words: IMO "locked" must stay, we may only discuss how it behaves.

My opinion:

The confirmation request "Selection contains locked items. Do you want to continue?" is fine in actual versions, when a single locked footprint is concerned.

If more locked FP's are concerned, a list of locked items with individual checkboxes should be displayed (->wishlist)

My answer to the original question (if to "disable locked items in selection clarification list") is negative. Do *not* omit locked items from Clarification list. I'd close this thread with "won't fix", and file a new wish:
A list of locked items with individual checkboxes should be displayed if one or more locked FP's are concerned in a move (or kind of that) operation.

Wayne Stambaugh (stambaughw) wrote :

On 8/7/2016 7:47 PM, Novak Tamas wrote:
> The mother language of 90% of mankind is not English. You should make it
> easier to use KiCad for them (with at most mid-quality English) using
> simple words: IMO "locked" must stay, we may only discuss how it
> behaves.

We are not talking about other languages unless locked is word in other
languages. Don't other languages have a word for locked? The meaning
of the word locked is pretty clear in English. If we are using word
locked when something really isn't locked, than we should consider using
a more appropriate work or phrase to prevent confusion.

>
> My opinion:
>
> The confirmation request "Selection contains locked items. Do you want
> to continue?" is fine in actual versions, when a single locked footprint
> is concerned.

Warning dialogs like this must be optional. I've made my feelings clear
about nagware. I will not reiterate them again.

>
> If more locked FP's are concerned, a list of locked items with
> individual checkboxes should be displayed (->wishlist)
>
> My answer to the original question (if to "disable locked items in selection clarification list") is negative. Do *not* omit locked items from Clarification list. I'd close this thread with "won't fix", and file a new wish:
> A list of locked items with individual checkboxes should be displayed if one or more locked FP's are concerned in a move (or kind of that) operation.
>

Wayne Stambaugh (stambaughw) wrote :

Sounds like we really want fine grain locking. In other words, lock
position, lock layer, lock orientation, lock editing, etc. This will
complicate locking but it could be done and the intent of the lock would
be clear. As of right now, lock is ambiguous because it only locks some
things but which things are locked is not obvious.

On 8/7/2016 7:02 AM, jean-pierre charras wrote:
> Well, even for an English speaker, locking a footprint needs to be defined.
> I am (obviously) not an English speaker, but I am thinking a locked footprint cannot be moved, rotated, flipped or deleted (at least without prompting the user).
> I could call these changes "geometrical changes" or "topological changes".
>
> However it can be (partially) edited:
> Fields(ref, value) can be moved/edited.
> Netlist can be updated.
> Netlist can change the footprint (but not delete it, because it can be added outside the netlist, for instance mechanical holes).
>
> The issue is just the user is not always asked for these geometrical
> changes.
>

Jeff Young (jeyjey) wrote :

The action-specific pruning of the selection can now be done with the new selection filter architecture.

1) I've logged a different bug for figuring out exactly what lock means and implementing it uniformly.
2) Numbers/hotkeys in the Clarify Selection menu have been implemented.
3) I'll leave this bug open for action-specific pruning of locked items in 6.0

Changed in kicad:
assignee: nobody → Jeff Young (jeyjey)
Bob Cousins (bobcousins42) wrote :

Natural languages are always a bit fuzzy when applied to precise technical concepts.

In English, "locked" means internal access is prevented, e.g. a briefcase, but may still be moved.
"Immobilized" means an object is prevented from movement, but potentially the internals could still be accessed. The two concepts are generally separate, but in specific cases like a vehicle, locked could be assumed to mean immobilized, but not necessarily.

The terms I might use are "locked for editing" and "locked for movement".

Jeff Young (jeyjey) wrote :

We should prune locked items and hidden items. Right now clicking on a hidden pad will select it over a track that runs under it.

Jeff Young (jeyjey) on 2018-02-13
Changed in kicad:
milestone: none → 6.0.0-rc1
Jeff Young (jeyjey) on 2018-02-17
Changed in kicad:
importance: Undecided → Low
KiCad Janitor (kicad-janitor) wrote :

Fixed in revision 37f7faf4336e37c8df4116d2a67379ef73da4ccf
https://git.launchpad.net/kicad/patch/?id=37f7faf4336e37c8df4116d2a67379ef73da4ccf

Changed in kicad:
status: Confirmed → Fix Committed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers