The Move tool does not snap to the center of a non-copper shape

Description

Steps to reproduce

1. As shown in the figure, moving the pad to the center of the F.Silkscreen layer does not automatically adsorb. Convert it to F.Cu layer and you're ready to adsorb.

KiCad Version

Application: KiCad x64 on x64

Version: 8.0.0-rc1-79-gf80094e7c5, release build

Libraries:
	wxWidgets 3.2.4
	FreeType 2.12.1
	HarfBuzz 8.3.0
	FontConfig 2.14.2

Platform: Windows 10 (构建 19045)，64位版, 64 bit, Little endian, wxMSW

	wxWidgets: 3.2.4 (wchar_t,wx containers)
	Boost: 1.83.0
	OCC: 7.7.1
	Curl: 8.5.0-DEV
	ngspice: 42
	Compiler: Visual C++ 1936 without C++ ABI

Build settings:

added 8.0 priorityundecided statusnew labels

I think this depends on your layer snapping settings. It seems like you're in "active layer snapping" mode - try pressing shift+S to change to "all layer snapping" mode.

But after I switch to the F.silkscreen layer, the center of the F.silkscreen layer cannot be captured, and the same is true for other layers, only the center of the copper layer can be captured arbitrarily

I think this is because the pad is on a copper layer, so in "active layer" snapping mode it'll only snap to copper layers (maybe the option is a bit misnamed). If you were moving a silk object in "active layer" mode, it would only snap to silk objects, regardless of what the current layer is.

That's true, but the active layer in snap mode doesn't mean much, I thought it was the left column that was selected as the active layer, but in fact the mouse selected object was the active layer, and the pad belonged to the copper layer

Right. I agree with you, to me "active layer" means the layer that I have selected in the appearance panel, but it actually means the layer of the active object.

(actually, I think it would be great to have three options here that you could cycle between: all layers, the active object's layer, and then a new option for snapping only on the selected layer in the appearance manager).

I have updated the action names & tooltips as follows:

TOOL_ACTION PCB_ACTIONS::magneticSnapActiveLayer( TOOL_ACTION_ARGS()
    ...
    .FriendlyName( _( "Snap to Objects on Restricted Layers" ) )
    .Tooltip( _( "Restricts snapping to objects on the active layer while drawing, "
                 "and to objects with shared layers while moving" ) ) );

TOOL_ACTION PCB_ACTIONS::magneticSnapAllLayers( TOOL_ACTION_ARGS()
    ...
    .FriendlyName( _( "Snap to Objects on All Layers" ) )
    .Tooltip( _( "Enables snapping to objects on all visible layers" ) ) );

TOOL_ACTION PCB_ACTIONS::magneticSnapToggle( TOOL_ACTION_ARGS()
    ...
    .FriendlyName( _( "Toggle Snapping Between All Layers and Restricted Layers" ) )
    .Tooltip( _( "Toggles between snapping on all visible layers vs restricted layers "
                 "(the active layer while drawing, or shared layers while moving)" ) ) );

@kicad/code/lead_devs technically a bug, but I'm not sure how important vs. string freeze. Shall I check it in to 8.0 or 9.0?

@jeffyoung I recommend 8.0! This is an 8.0 bug, not a new feature

My understanding of the policy was it was only supposed to be spelling and grammar fixes after string freeze, so I don't think it meets the criteria of that for 8.0.

Spelling, grammar, and factual inaccuracies.

It doesn't seem like the original strings were inaccurate; this is just changing them to be more clear. I don't think it meets the bar for changing the strings at this point, personally. I would suggest we just try to explain this in the user manual.

Technically, it is inaccurate. It says "Active Layer" when it is not, in fact, the active layer (it's any layer shared with the moving objects).

(Just to be clear, I don't feel strongly one way or the other.)

Hmm, I would need to go look at the code and play with this, but is that a bug? Why do we snap to "shared layers" rather than just the active layer?

@sethhillbrand intentionally changed it to do that way back in 2019 (for lp:1830164).

That seems a complicated / unintuitive bit of extra logic now that we have an all-layer snap mode.

Well, removing it would also fix the bug, and without any string changes.

Yeah, it was a stop gap looking at the issue as the problem was raised during a feature freeze

closed with commit 37c185f4

assigned to @jeffyoung

changed milestone to %8.0

added prioritylow statusfix-committed labels and removed priorityundecided statusnew labels