IMPORTANT : You’ll have to click the images to see everything, the site’s compression completely hides the intended information in many of the screenshots.
While selected, clicking and dragging a footprint to the right of its origin anchor warps the mouse to the footprint origin.
While selected, clicking and dragging a footprint to the left of its origin anchor warps the mouse to an unspecified (but consistent) off-grid location. The mouse will then snap to the closest grid location if moved (biasing the footprint an unspecified non-grid distance before all further moves follow the grid).
What is the point of this? The footprint can be right-side moved first to a grid location and then in grid increments. If the left-side movement snapped to an on-grid location, it could alternatively be left-side moved from its present location in exact grid increments without losing its original bias to the grid; however, presently, left-side movement just mucks all reference to anything.
Note : I moved the mouse down-right, first to grid and then 3 increments down and 3 increments right such that the warp location (grey orthagonal long lines), mouse (grey cross), and footprint origin (small purple cross) could all be seen clearly.
See that the warp location is off grid, and as a result, the purple origin — originally halfway between two points — has neither snapped to grid nor kept its original bias from the grid.
I also can not reproduce. I did not respond yesterday because I also do not fully understand the issue. I have been experimenting a bit with dragging to the left and right to move a footprint (a 2 pad SMB) and it works as expected for me. The cursor always warps to the center of the footprint (or to a pad center if that is closer), and then it puts that entity on the grid.
A screenshot with a size of 1119 by 673 pixels which just shows a grid and two crosses does not mean much to me. It’s placed too far out of context.
Is it dependent on the footprint?
Is it dependent on the grid size? (I have seen bugs that only manifest themselves on some grid resolutions).
Can you make a screen recording of it that clearly shows the issue? It helps if you can make such a screen recording from a smaller area. For example, doing it with a two pad resistor and coarser grid size are things that both help with reducing screen size, and thus the amount of zooming needed.
I use vokoscreen for my screen recordings, and when using libx264 as the video codec, small video’s can be embedded both directly on this forum and on gitlab.
Posted minimum working example in the bug report.
Issue confirmed and explained there.
Click n drag right of footprint anchor warps mouse to footprint anchor.
Click n drag left of footprint anchor warps mouse to geometric center of footprint.
Due to use of -L variant of footprint (minimum space possible), some of the silkscreen exists outside of the courtyard, and puts a very slight asymmetry in the geometric center of the footprint.
This only occurs at some grid sizes, to be reviewed, and asks the question : Should silkscreen be considered in calculating the geometric center of the footprint, also to be review.
I have additionally asked for added click and drag behaviors to warp the mouse to the nearest on-grid point, such that it is very easy to move with any off-grid reference point an exact grid unit quantity.
