bad snap when dragging track

Bug #1820248 reported by Novak Tamas on 2019-03-15
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Seth Hillbrand

Bug Description

When I make final fine modifications of tracks, I can't achieve small pushes. See attached video, where I try to set track to the middle of the space. I'm moving mouse cursor very slowly...still track is jumping only to a "distant" position.

It seems that the original endpoint of the track (from before starting drag) is a snap-to point, so I can't do fine movements, as there is a snapping point (the original position) in proximity.

config: brand new nightly, Win7, OpenGL

Application: kicad
Version: (5.1.0-18-ga1ee5405a), release build
    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 7 (build 7601, Service Pack 1), 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:

Novak Tamas (novak-7) wrote :
Seth Hillbrand (sethh) wrote :

Hold down Shift while dragging to disable snapping.
Hold down Alt while dragging to disable the grid.

Changed in kicad:
status: New → Invalid
Novak Tamas (novak-7) wrote :

Sorry, Seth, I know there is a workaround, but IMO it *is* a bug. Previous versions (my oldest is nightly 8659 from October 2017) don't do this.
Using the workaround is a bit uncomfortable: press D to drag, then hold down Shift, move and click mouse, then release Shift.
The actual grid is 0.01mm, still track jumps to abt 0.3mm far, so it is not a normal snap-to-grid.
Please consider setting it to low importance confirmed if you can reproduce the issue.

Jeff Young (jeyjey) wrote :

This has been coming up a lot. Even if we think it's valuable, perhaps snapping to 1/2 the track width or something would be better?

Or do we really need it at all?

Seth Hillbrand (sethh) wrote :

Well, it is already an option. If you don't like snapping to tracks, then you can turn it off in the preferences. I'm fine with making the snap radius configurable as well.

Jeff Young (jeyjey) wrote :

This isn't really snapping to tracks but rather snapping to itself. The former is useful for connecting things; this is not (although it may be useful for other things).

Seth Hillbrand (sethh) wrote :

We could remove the original trace from the SetEndItem calculation and instead rely on the auxiliary axis for snapping to the original position. That would allow grid override when the mouse is closer to a grid line than the origin lines.

@Novak- Would that address your request?

Novak Tamas (novak-7) wrote :

The Preferences - Pcbnew - Magnetic points - Snap to Tracks is set to "When creating tracks". I don't know if this should be valid for dragging tracks already connected...If I set this to "never", no snapping occurs, you are right. It is a better workaround than holding down Shift: I can set Snap to Tracks to Never for final track alignment phase.

Please explain to me what is this behavior good for: snapping to original position while dragging a track segment?

It is important for me to be able to drag the track segment, parallel to itself, by any (very small) offset. That is the usual final phase of work for me:
I drag vias and track segments to align/divide the spaces equally between adjacent tracks. This is where I need the small moves, and very annoying this snap-to-whatever (it is not snap to grid, as grid is set to very fine 0.01mm at this step). Using Shift for disable snapping is unpleasant for hundreds of small re-arranges.
So this is the "cons", and I can't see any "pros". And again this behavior grew up lately: nightly 12519 and 12228 show this issue, but 8659 does not.

Jeff Young (jeyjey) wrote :

When I do a 'G' on the end of a track I want it to snap -- so I don't want to set the preference to "When creating tracks".

However, I don't think I ever want 'D' to snap. At least I can't think of any case right now....

Seth Hillbrand (sethh) wrote :

If you want to eliminate jags in the track, you want to snap. This is almost always my use case when I am dragging tracks with 'd'

Jeff Young (jeyjey) wrote :

Hmmm... yes, good point.

Maybe we could differentiate between snapping to another segment and snapping to the original location?

Seth Hillbrand (sethh) wrote :

Right. @Novak, can you see if tomorrow's nightly works correctly for your use case?

KiCad Janitor (kicad-janitor) wrote :

Fixed in revision 0de25e557b45a9bccf3a0dbd59b208334f4b8b3f

Changed in kicad:
status: Invalid → Fix Committed
assignee: nobody → Seth Hillbrand (sethh)
Seth Hillbrand (sethh) on 2019-03-17
Changed in kicad:
milestone: none → 6.0.0-rc1
Novak Tamas (novak-7) wrote :

@Seth, ok, I will check next nightly.
One more thought: you should differentiate between a new track segment where its free end to be connected to some snapping point,
and a segment having been connected and dragging.
It's everything is fine at the "laying new track" case.
At the "dragging an already-placed segment" case the only object(s) to be snapped to is
- parallel segments of the same net
- grid
but definitely not the old position.

Novak Tamas (novak-7) wrote :

@Seth, I checked 12544 of March 22th, but I don't see any change. See video again. I
- move he cursor above the track,
- push D to drag
- slowly move mouse, but track is *not moving* at first
- track is suddenly jumping to a farther position, then gently following the mouse cursor
- when I move back toward the original position of the track, it is jumping back to its original posistion from a distance.

I think that when dragging is initiated, a list of snap-to objects made, and the original position goes to that list, which it wouldn't!

Seth Hillbrand (sethh) wrote :

Apparently, I only got the disconnected end case. OK, back into the queue.

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

Other bug subscribers