snap to object feature now only works for things on the same layer

Bug #1830164 reported by Rene Poeschl
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
KiCad
Expired
Low

Bug Description

I seem to remember that the snap to objects feature worked with respect to any layer no mater which layer the snap target is on. Right now this seems no longer to be the case.

To test this draw some lines on the edge cuts layer.

And then try to snap to that while drawing on the silk layer.

---

This is also the case with the move command when the group one moves contains things from multiple layers. Lets draw some lines on edgecuts and one on silk as the moved objects plus a reference line on the edgecuts layer. As long as one does not include the line on silk in the moved group it is possible to snap to the edge cuts line. This stops working as soon as the silk line is included.

---

Application: kicad
Version: (5.1.2)-1, release build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.61.1 OpenSSL/1.1.1 (WinSSL) zlib/1.2.11 brotli/1.0.6 libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.5) nghttp2/1.34.0
Platform: Windows 8 (build 9200), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8)
    Boost: 1.68.0
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.61.1
    Compiler: GCC 8.2.0 with C++ ABI 1013

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_PYTHON3=OFF
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON

Tags: pcbnew
Rene Poeschl (poeschlr)
description: updated
Revision history for this message
eelik (eelik) wrote :

I notice the same thing with nightly builds. If "Snap to graphical" is on in the preferences it still snaps to the same layer only.

If some people find snapping only to the same layer useful or vice versa, maybe it could be made optional in preferences.

Application: KiCad
Version: (5.1.0-657-g323ecada8), release build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.61.1 OpenSSL/1.1.1 (WinSSL) zlib/1.2.11 brotli/1.0.6 libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.5) nghttp2/1.34.0
Platform: Windows 8 (build 9200), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8)
    Boost: 1.68.0
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.61.1
    Compiler: GCC 8.2.0 with C++ ABI 1013

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_PYTHON3=OFF
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON

Seth Hillbrand (sethh)
Changed in kicad:
importance: Undecided → Low
status: New → Triaged
tags: added: pcbnew
Changed in kicad:
milestone: none → 5.1.5
Revision history for this message
Seth Hillbrand (sethh) wrote :

Can we define the layers to/from which this should always snap? Too many and we'll just be overwhelmed.

For example, drawing with Edge.Cuts should snap to all technical layers but no copper layers. Drawing with silk should snap to silk, Dwgs, Eco but not edge cuts. Dwgs and Eco should snap to everyone.

Other thoughts?

Revision history for this message
eelik (eelik) wrote :

That makes sense. Documentation layers should snap to pretty much everything. Also snapping to pads is important because the documentation layers may be used for help for aligning etc. At the moment (with quick test) Eco1 doesn't snap to pads in nightly builds.

Revision history for this message
Wayne Stambaugh (stambaughw) wrote :

I would be careful with any layer snapping restrictions. My guess is that users will complain if we limit what layers snapping is enabled based on the current layer and the chances of us getting all use cases correct is low. A better solution would be to allow users to configure layer snapping as they see fit.

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

Configured snapping is definitely better. This would be in a separate panel so I would venture this to be in the new feature territory. Should be push this into 6.0?

Revision history for this message
Wayne Stambaugh (stambaughw) wrote :

This is definitely a new feature. I'm not sure we have the manpower to make it happen in v6 but I suppose it wouldn't hurt to add it. We can always defer it to v7 if we don't have time to get it done for v6.

Seth Hillbrand (sethh)
Changed in kicad:
milestone: 5.1.5 → 6.0.0-rc1
Revision history for this message
eelik (eelik) wrote :

Configuration options would be a new feature, but how about enabling snapping at least for some layer combinations for 5.1 and leaving the UI for 6 (or later)? I remember, as did Rene, a time when drawing tools snapped to other layers, and I used it. So I wouldn't say it's a new feature :)

In the end it's about what's better, snapping possibly too much or snapping too little. I would say too much is better in this case.

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

@eelik-

Not saying that your memory is incorrect but I don't recall this being the case. Certainly, the first implementation [1] that added snapping for graphical items explicitly was layer-dependent. It was explicitly implemented to avoid the unclosed outline issues in 5.1.

I'm fine with adding additional snap targets based on the source layer in 6.0. Wayne is right that we'll get requests for additional snap targets based on user preference. I _might_ get to a preference panel but that's lower priority than almost any other targeted item on my 6.0 list. Until then, if someone wants to document the correct snapping combinations, I'll put those in as a stop-gap.

The issue where a group doesn't allow snapping to the full group layer set is a bug and will be fixed.

But snapping to everything with no limit is a non-starter (for me at least) until we have it configurable.

[1] https://git.launchpad.net/kicad/patch/?id=03e642a8db445e59c8a9d31662e0f3ae3237f25c

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

Fixed in revision 8576668eba0d620911d3f32f91b90d7a46cf5980
https://git.launchpad.net/kicad/patch/?id=8576668eba0d620911d3f32f91b90d7a46cf5980

Changed in kicad:
status: Triaged → Fix Committed
assignee: nobody → Seth Hillbrand (sethh)
Revision history for this message
Seth Hillbrand (sethh) wrote :

Setting back to triaged as this only addressed part 2 of the bug report

Changed in kicad:
status: Fix Committed → Triaged
Revision history for this message
eelik (eelik) wrote :
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/1900

Changed in kicad:
status: Triaged → Expired
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.