Move Relative and Move Item in PCBNew don't move selection properly

[Art]

I'm trying to select the whole board and flip it and move. Neither dialog (Ctrl-M or Ctrl-R) are working properly. I can't even figure out what the heck is going on. The board is not rotating along origin selected. It seems to be rotating along some random coordinate. The move is not working either. To simplify I select the whole board and try to move it by 2 inches along Y axis. Instead it moves more than 2 inches along Y and it moves about half of that along X axis. When I switch the units to mm, Move Relative stays in inches.

BTW why is there two identical (albeit not working) tools there?

Application: kicad
Version: (5.0.0-rc2-dev-720-g9704891c8), release build
Libraries:
    wxWidgets 3.0.3
    libcurl/7.54.1 OpenSSL/1.0.2l zlib/1.2.11 libssh2/1.8.0 nghttp2/1.23.1 librtmp/2.3
Platform: Windows 8 (build 9200), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
    wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8)
    Boost: 1.60.0
    OpenCASCADE Community Edition: 6.8.0
    Curl: 7.54.1
    Compiler: GCC 7.1.0 with C++ ABI 1011

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

[Robbert Lagerweij (rlagerweij)]

Art, you reference two separate tools but it is not clear to me which tool is doing what wrong in the rest of your problem description.

Could you separate the (1) actions, (2) expected result and (3) actual result by tool and by function (i.e. move and rotate). I'll take a look at the move exactly tool based on such more specific description.

[Art (diametrix)]

In the time that it took you to type that response you could've simply tried both tools and see for yourself. I would imagine it wouldn't be that hard to replicate the problem. Like I mentioned before I don't see any rhythm or reason behind how the tools operates. Regardless, here is a break down by the tool and operation, for those who can't be bothered to try it themselves.

I have a PCB positioned so that top left corner is in the x=0, y=0 coordinate. I will do all the moves starting from this initial state. I will also attach pictures of each result. I will manipulate only top copper layer so the rest of the board stays in place and gives you a reference as to how the board actually moved

Position Relative tool:

1. Item Rotation : 90 deg Anchor point selected at x=0, y = 0. I would expect the board to be rotated 90 degrees around its top left corner. However the board is rotated 90 degrees counterclockwise and roughly the middle of the board is placed at the origin.

2. Move vector X (btw who came up with that name?): select 50 mm. Anchor is still x=0 and y=0. Everything else is at 0. Result - the board is moved 39mm to the right and 4.5 mm down

3. Move vector Y: select 50mm. Anchor is still x=0 and y=0. Everything else is at 0. Result - the board is moved 54mm down and 11 mm to the left

Move Item tool:

1.1 Item Rotation (current position) : Not sure what current position is supposed to be but when selected the board is rotated 90 degrees CCW and the top left corner of the board is now below and to the left of the origin.

1.2 Item Rotation (sheet origin) : the board is rotated 90 degrees CCW and the top left corner of the board is still below and to the left of the origin, albeit the new position is somewhat higher than the previous result.

2. Move vector X (sheet origin): select 50 mm. Everything else is at 0. Result - the board is moved 24mm to the right and 33 mm up

3. Move vector Y(sheet origin): select 50mm. Everything else is at 0. Result - the board is moved 17mm up and 25 mm to the right

[eelik (eelik)]

See also https://forum.kicad.info/t/what-is-position-relative-to/10762/4.

Move Item (called Move Exactly in the menu - the dialog title should be changed) works just as expected for me, but I have used it mostly for single items.

Selections consisting of multiple items seem to be problematic for these movement functions because it's not possible to select the reference point in the selection. I guess that when several items are selected they are almost never laid out with the center of their "bounding box" in mind. Therefore the geometric center of the selection is as good or bad a reference point as any random point. It's impossible to do any meaningful movements for them except relative to their original position.

Actually the possibility to use these functions with several selected items instead of just one looks like an afterthought. Even the Move Exactly dialog title reflects that.

As a cure I suggest that it should be possible to select the selection's reference point. Now there's "Override default footprint anchor with" selection in the Move Exactly dialog. That should be an option only with a single footprint. Otherwise it should allow at least these possibilities:

- centerpoint of bounding box (the current automatic behavior)
- top left corner of bounding box
- top right
- bottom left
- bottom right
- and especially ability to select the point manually.

The easiest way to select the point manually would be to use the point on which the context menu was opened, i.e. "Current cursor position". That way the user could select any point beforehand.

And it's true that these two functions/dialogs could be only one. Just add an option to Move Exactly dialog to select the reference point manually. On the other hand, now it's possible to use User or Grid origin which kind of makes an extra reference point unnecessary (unless the user for some reason wants to keep them intact while still using some custom reference point for this movement only).

[Art (diametrix)]

>>>Selections consisting of multiple items seem to be problematic for these movement functions

There is really no difference between moving a single item or a selection of items, from the programming standpoint

>>>....because it's not possible to select the reference point in the selection

I beg to differ, in the Relative Move menu there is an attempt to select a reference point. You click "Select Anchor Item" and then go and click anywhere in the board and once in a while you will be able to select a point. Lame implementation aside, it illustrates the idea of how it CAN be done. However I don't see that being a very useful feature - may be in certain isolated cases. Much more useful would be entering reference point manually (which, again, can be done in the current version of Relative Move menu.

Something else to keep in mind, the reference point is needed only for rotation, you don't need it for horizontal or vertical move. The text boxes in the menu should probably be grouped together so it would not be misleading. You can even have reference point items to be greyed out while rotation angle is at zero. And I would rename "Anchor Item" into reference or origin. We are not anchoring anything, it is just again misleading.

>>>The easiest way to select the point manually would be to use the point on which the context menu was opened

That's a bad idea. After you made your selection of items (box selection or otherwise) you have a regular mouse pointer cursor that doesn't snap to grid or anything else for that matter. It is close to impossible to position that cursor precisely, which makes that feature completely useless. Again, you need a reference point only for rotation and before you rotate, you pretty much already know the coordinates for your reference point.

I'll give you an example. What I was trying to do originally is to move my board in such a way that the bottom right corner would be in the origin and the board would be horizontal and to the left of the sheet (in needed it to generate component position file for the SMT machine properly - which can be another improvement in KiCad but is a topic for another discussion) I know my board dimensions of the top of my head 2 inches in X and 2.52 inches in Y. The top left corner of my board is at the absolute origin. So I can do this in multiple ways without trying to select anything:

1. Rotate the board around X=1" and Y=1.26" and 2. Move up by X= -2.26 and Y = -2.26
or
1. Move the bottom right corner into the origin, so X = -2" and Y = -2.52" and then 2. Rotate around the origin, so X = 0 and Y = 0

I can do this without really doing any calculations and every move is precise and not ambiguous ... or I should say "needs to be precise and not ambiguous"

And one more final thought. In the current configuration there is an ambiguity about the order of operations. Examples above illustrates it clearly, that if you do rotation first and then linear move you will get a different result from the one when you do move first and then rotate the board around the same fixed point.

[Novak Tamas (novak-7)]

For me Ctrl-M seems to work fine with x-y relocations. (I never tried rotating here as it's original function is Move).
Ctrl-R is a real mess. One strange but easy to understand thing is rotating directon: CCW=positive , and CW=negative.

See my video: board top left is at (0;0), size is x=65 y=36mm.
When I Ctrl-R the whole board with parameters all 0, board's top left point (0;0) goes to +32.5 and -18.75999. These coordinates are almost half board: it seems moving is defined somehow by the coords of the center of the bounding rectangle (with little Y error)

Center point of bounding box is +32.5; +18

Now top left goes from (0; 0) to (+32.5; -18.....)

Changed Y direction explains opposite CW/CCW

[eelik (eelik)]

@Art - I also beg to differ. You always need two "reference points", one external and one internal to the selection (moved item). You can't, for example, put a rectangle into a coordinate system unless you have one point of/in the rectangle which is the reference point. There just doesn't exist such entity as "rectangle with position x,y". X,y is always a position of a point by definition. It must first be defined to be the position of the rectangle's geometric center, bottom left corner or something like that. Only after that it's meaningful to speak about moving the rectangle to the point x,y relative to some other point.

What I'm thinking about is the situation where for example I would use some pad's center point as the external reference point and then would move some selected items relative that external point. Most probably I have some certain point within the selection in mind which should be in the target coordinates. And most probably it's not the bounding box's center, unless it's just one (symmetric) footprint or pad.

">>>>>>The easiest way to select the point manually would be to use the point on which the context menu was opened

>>>That's a bad idea. After you made your selection of items (box selection or otherwise) you have a regular mouse pointer cursor that doesn't snap to grid or anything else for that matter. It is close to impossible to position that cursor precisely, which makes that feature completely useless."

You're wrong. The KiCad's cursor is different than the mouse cursor. KiCad's internal cursor or whatever it's called snaps to the grid even after selecting something. It's also possible to snap to the center of pads or vias if you have chosen that preference and use the track tool or the measurement tool. It even works like this: 1. Select something. 2. Go somewhere so that the KiCad cursor snaps to something. 3. Open the context menu. The menu is opened for the selection, not for the item on top of which the cursor is.

So, if the context menu opening position (the KiCad cursor position, not the mouse cursor position) is known it could be optionally selected as the reference point in the dialog. Actually either the internal or external reference point, or even both if you would like to have something confusing :)

[Art (diametrix)]

@eelik
>>> You always need two "reference points", one external and one internal to the selection(moved item).

That's a fragmented thought. You need two reference points for what? You don't need any reference points at all for a linear move. You need a single origin for the center of rotation. Where are you getting two reference points from? I'm sorry, i didn't understand anything else you were trying to say. Regardless, I'm not here to explain geometry 101, I'm just reporting a bug.

>>> You're wrong. The KiCad's cursor is different than the mouse cursor.

Please tell me you are not involved in KiCad development. You might want to actually try to use it before you claim something about its operation. See a short video attached depicting a board selection process and what mouse cursor is available after that.

[eelik (eelik)]

@Art
I'm not a KiCad developer, at least not at the moment, so you don't have to be afraid I could affect others so that the bug wouldn't be fixed. Maybe I should have made it clear from the beginning. I only noticed this bug report and I had experienced partially same problems with these dialogs. I wanted to share it.

I'm also sorry about not being more clear about my focus which was about moving items, not about rotating. Maybe that's why you don't understand what I'm saying. Rotating needs only one point. However, moving an item relative to other than its original location needs two reference points even if you don't feel you need them.

The first one is the "Move Relative To" position in the "Move Exactly" dialog. The second one is the center point of the selection or some other point in the selection. If there weren't any such point, you couldn't give any meaningful interpretation to the "Move vectors". Only if you move an item relative to its current position you don't need reference points because you can think about length and angle (a vector) instead of location. But the other options, "User origin", "Grid origin" etc. require a location instead of just a vector. And you can't put e.g. a rectangle into an x,y location unless you first know which point of the rectangle should be in that location. What these options logically do is putting the selected item into some coordinates instead of just moving it along a line (vector).

I'm sorry I can't express myself more clearly, but that's not the point (and sorry about the pun, too...). I'm sure the developers can see your point and mine.

About the cursor - I know very well how it works because I carefully tested it before a wrote my comment. If you select Full window crosshair and Always display crosshairs in Display Options and then choose a grid value large enough (or zoom close enough) you can very clearly see how the KiCad crosshair cursor snaps to the grid while the mouse arrow cursor doesn't. It's also reflected in the X and Y values in the bottom of the window. And what's more, this (X,Y) location stays the same after the context menu is opened and the mouse cursor is moved. Selecting something doesn't affect this.

At least in Linux, latest KiCad source code from git, with the Modern Accelerated toolset.

Unfortunately I couldn't get the video playing, maybe it's my Linux system. Probably it would have helped me to understand what you meant.

[Art (diametrix)]

@eelik

Way to over-complicate things. First of all you don't really need a move relative option at all, it is just confusing. A simple absolute move would suffice. Even if you can't do simple math in your head to figure out a move of an object from its current position as it is related to a position of another, you can just do it in two simple jumps. First move one object to the position of the other and then do the relative move. However, in all my years doing board layout I never remember a case when I needed to do that. The only utility of this tool that I see is moving selections of multiple objects, otherwise it is easier to do it by hand. And even if this option is so dear to your heart you still need only one reference point. Trying to move a certain point of an object relative to another coordinate is just asinine. If anybody ever will need that option, that's fine with me - implement it AFTER you get a simple absolute move to work.

>>>About the cursor...If you select Full window crosshair and Always display crosshairs in Display Options

...and if you do a little dance with a tambourine. Aaaand if you don't? What happens then? Let's stick with the default options as a starting point. Even if you enable all those options, you still can only jump between the grid points, which is not much help at all in selecting a reference point tied to an object.

[Jeff Young (jeyjey)]

@Art, a little less confrontational, please.

[Seth Hillbrand (sethh)]

I see that reporters don't really like how the dialogs work at the moment. Let's come up with a clear suggestion for how how we want the dialogs to work. Personally, I like how the move dialog works currently and use it frequentyly but maybe that's just because I am used to it.

I would also like to know what problem we are trying to solve -- as in what are we trying to do that we can't -- before changing something (even then, we're probably talking about v6 unless there's an actual bug here)

[eelik (eelik)]

I kind of hijacked this thread and am sorry about that. Yes, there might be several issues. Art's most important, as far as I can see, was about rotating. I focused on moving and on Move Exact dialog. I already thought about opening another issue for that, making clearer what I would propose, but kind of lost interest for a while. Is it OK if I open another report?

[Art (diametrix)]

@Seth
>>>I would also like to know what problem we are trying to solve -- as in what are we trying to do that we can't -- before changing something

Can I ask you in turn, what exactly you didn't understand in my bug description and the following example , which compared both tools. I can't possibly fathom how you can enjoy the functionality of the current tool, since it is completely unusable.

>>>Let's come up with a clear suggestion for how how we want the dialogs to work.

Here is a clear suggestion for you - we want it to WORK! When I select a move along a single axis and enter a distance value, I expect the board to move along that exact axis by that exact distance. I know it is really picky of me, but I'm just that difficult. The same for rotation - if I pick an origin of rotation and enter an angle, I expect all selected objects to rotate around that particular origin by the number of degrees I had selected. It is crazy stuff! Cutting edge of the rocket science and all.

[Robbert Lagerweij (rlagerweij)]

@Art
>>> I know it is really picky of me, but I'm just that difficult.

Trust me if I say that you pickiness is not the difficult part of you.

>>> When I select a move along a single axis and enter a distance value, I expect the board to move along that exact axis by that exact distance.

Art, the move dialog will work exactly as you would expect when you select "current position" as an origin.

Now despite your outright abrasive behaviour here, you are right on two things related to the move exactly dialog, namely (1) the rotation function is ambiguous and using it can lead to unexpected results and (2) the dialog text is not entirely clear. It would have been better to have named the origin to be something like "move starting point". Then it would be clear that for the function you want, you should have selected "current position" and that selecting any other option makes the move absolute rather than relative.

Once you move into absolute movement then the comments that eelik made in #10 and #13 become relevant. Currently when moving a selection of items to an absolute position will place the centerpoint of that selection on the specified coordinate. You can override that to the top left pad in the selection by using the bottom drop down. Here there is another situation of unclear text since I should have removed the word "footprint".

I would suggest (for 5.1 given the string freeze currently in place) that I fix the strings and we move the rotation to a separate tool.

>>> Here is a clear suggestion for you - we want it to WORK!

And please stop being so aggressive, it is off-putting

[Seth Hillbrand (sethh)]

Thanks Robert and eelik, these sound like good suggestions. Let's re-address during 5.1

[Art (diametrix)]

@Seth
>>>Trust me if I say that you pickiness is not the difficult part of you.

Let’s not get personal here. You can pm me all your feelings and grievances.

Back to the subject at hand.

1. I’m still not sure what part of the bug description you were not clear about

>>>Art, the move dialog will work exactly as you would expect when you select "current position" as an origin.

2. If you actually read both of my initial posts (try not to melt here, I’m just saying it sound like you didn’t or just it didn’t stick), you will see that I wasn’t able to make a simple move work for any of the origin options I selected. Your experience may be different, but I can’t speak for that, I’m simply describing what I’m seeing on my machine

3. I don’t think that the problem lies in naming ambiguity of various options. Even if you disregard the fact that it doesn’t really work in its current implementation, the intent of the designer was just all over the place. Again, we are not performing orbital calculations here. We are doing a simple move and rotate. How confusing can that be? Or rather how confusing should it be? Sometimes more options is not better. I’d rather do something in several steps with a simple and clear interface, than try to muddle my way through all of the confusing options, just to end up with a unexpected result.

[eelik (eelik)]

Taking rotation out of the Move dialog(s) and making it a dedicated dialog would at least help with one ambiguity. "I’d rather do something in several steps with a simple and clear interface" - yes, and a dedicated Rotate dialog would help with that.

But I, too, can't understand why you didn't succeed in a simple movement. Personally I wouldn't even try the Position Relative To dialog, it's useless IMO. Please see the attached screenshot of the Move Exactly dialog. If you have those options - there's actually nothing but "Move Relative To: Current position" to check, and AFAIR it's checked by default unless you have chosen something else - it does exactly what you want. It just moves the selected items 2mm right and 1mm down. No orbital calculations or anything, and no bugs. It has worked every time I have used it.

Your screenshots showed the beginning and the end of the situation, but not what you actually did. If you still believe there's a bug in the Move Exactly dialog, show what you did. A screencast is the most accurate because then it's impossible to guess wrong or miss anything, but even static screenshot of the dialog before clicking OK would be good.

(BTW, I got the one video downloaded and played it. As far as I can see it's just static situation where a yellow selection box is visible, there's no action at all. If the video is what you intented, then we didn't understand each other at all and were talking about different things. But I don't think it matters because cursor wasn't the point at all and there's no need to discuss about it further.)

[Jeff Young (jeyjey)]

I don't think I'd move rotation to a separate dialog. I do agree that doing both at once just muddies the water, but we can have radio buttons in the dialog to chose which the user wants to perform.

We should also simplify the Move Exactly dialog to handle ONLY the straight-forward case: move relative to current position. Rotating a group of objects would rotate each one around its own anchor.

The Position Relative To dialog could then do all the complicated, anchor-relative stuff. I wouldn't add more anchors though; we already have a boat-load of origins. If they want to rotate around a point then they can place the User Origin there and then do the rotate. Similarly, if they want to move an object to an exact position relative to something else, then they can place the User Origin on that something else and then do the move.

[eelik (eelik)]

> "I don't think I'd move rotation to a separate dialog. I do agree that doing both at once just muddies the water, but we can have radio buttons in the dialog to chose which the user wants to perform."

I agree about separate dialogs. However, tabs would be more natural if the purpose is to reduce clutter and confusion. On the other hand, then, it would be unclear whether it would still do both if the user edited first one and then the other tab... Maybe then radio buttons which would change the rest of the dialog?

> "We should also simplify the Move Exactly dialog to handle ONLY the straight-forward case: move relative to current position. Rotating a group of objects would rotate each one around its own anchor. The Position Relative To dialog could then do all the complicated, anchor-relative stuff."

Sounds reasonable, I wouldn't object.

> "If they want to rotate around a point then they can place the User Origin there and then do the rotate."

That's true.

> "Similarly, if they want to move an object to an exact position relative to something else, then they can place the User Origin on that something else and then do the move."

It's unclear for me how all possible use cases would be covered with the now existing options. How would you, for example, move a pad so that its bottom right corner would be in certain coordinates relative to the top left corner of another pad? If it should be done without changing the grid or grid origin.

I have added a quick mockup UI for moving, I think it looks quite simple. When the dialog would be opened the cursor position would be set to the current position (the position of the right click, if the dialog was opened that way.

It would be possible to set the cursor almost as it now is possible in the Position Relative dialog, except it wouldn't select items.

This is a further wishlist item, not so important: when positioning the cursor it should be possible to snap to certain points. Otherwise it's sometimes pretty impossible to hit e.g. a center of a pad. Probably it should be possible to do without snapping, too. And when it would snap it should be possible to snap to each end and start point (of graphic lines etc.). Also each corner of pads/footprints/bounding boxes, if those weren't covered in the anchor options.

This way (almost?) all imaginable use cases would be covered. Simple cases wouldn't be too difficult, less simple possible.

[Jeff Young (jeyjey)]

> How would you, for example, move a pad so that its bottom right
> corner would be in certain coordinates relative to the top left
> corner of another pad?

I don't think we need to support that kind of thing entirely with the GUI. We can't arrange 6 pads at 30º intervals to form a circle in a single step either.

To accomplish it they can place the User Origin at the top-left of the other pad and then do a Position Relative To making use of the numeric evaluator.

Assuming a desired distance of 100mils and a pad width of 32mils they'd type in:

Move vector X: [ 100 - 32/2 ]

[eelik (eelik)]

True, not all possible cases should be covered. But maybe my example wasn't so good. I still can't find a way to move a selection of several items so that e.g. one pad is the anchor of the selection. As a simple case, I would like to select the user origin - or not even that, just use the coordinate ("sheet") origin - and move the selected items so that one specific pad center would be exactly in the origin. This would be pretty easy if the current cursor position could be used.

[Jeff Young (jeyjey)]

Sorry, @eelik, I don't have much sympathy for that example either. ;)

Note, however, that this does not mean that I'm convinced there /is/ no better example. So if you think of others don't hesitate to post them.

[eelik (eelik)]

>"Sorry, @eelik, I don't have much sympathy for that example either. ;)"

Do you then have an alternative solution for that example? I can't imagine a better place to move a selection to exactly some point than "Move Exactly". But now I can't use it for multiple item selection. As I have said many posts ago, the center of the bounding box of the (asymmetric) selection is rarely the wanted anchor point.

[Jeff Young (jeyjey)]

> Do you then have an alternative solution for that example?

No, I'm just saying that I haven't ever used this function for anything beyond a simple Relative Move, so I'm not the best judge of what use cases might exist.

"Move Exactly" to me means Move By This Exact Amount, not Move To Exactly This Spot.

I 100% agree that the centre of the bounding box is useless as an anchor. But we don't need an anchor for Move By, which is why I like separating it out.

Rotation is a bit more difficult. In my first proposal I suggested that the Move Exactly multiple-selection case would rotate each item around its own anchor. But maybe even the simple rotation should rotate everything together around the User Origin (with a suitable help-string in the dialog).

[eelik (eelik)]

So would we have four tasks under the wider concept of "move"?
1. Simple move
2. Complex move
3. Rotate together
4. Rotate individually

In that case, wouldn't it be better to have 2 dialogs, Move... and Rotate...? Each would have two tabs:
1. Simple move (Move by, the default when opened for the first time)
2. Complex move (Relative to external point)

and

1. Rotate selection together
2. Rotate items individually

correspondingly. The Rotate dialog could be context-sensitive so that if there were only one selected item, it would have only the first option (maybe with different text).

[Jeff Young (jeyjey)]

Yeah, I might prototype up both of these and see which works better.

[Nick Østergaard (nickoe)]

@Jeff, I just stumbled across this bug and the last comment says you want to do something with it. I assigned you such that you can find it again. Feel free to unassign.

[Jeff Young (jeyjey)]

Yeah, I've actually already prototyped it in my 6.0 tree; I just forgot to assign it to myself and mark it In Progress. Thanks for the heads-up, @Nick.

[Jeff Young (jeyjey)]

Strawman for Move Exactly...

[Jeff Young (jeyjey)]

Strawman for Position Relative...

[Jeff Young (jeyjey)]

(With the picture this time.)

[Maciej Suminski (orsonmmz)]

The new dialogs look much more intuitive than the current ones. The only part that keeps me puzzled is "on all copper layers" in the Position Relative dialog: what do you exactly mean when specifying the layers? What are the options?

[Jeff Young (jeyjey)]

@Orson, that's just because I'm using the GetSelectMenuText() routine to generate a description of the reference item. It might be possible to get a status bar report or something for it that I can fish individual strings out of to be more appropriate.

[eelik (eelik)]

Here are screenshots from a move dialog without rotating and with two tabs. I still think that "Cursor location" would enable almost any use case. But to make it simple there would be no need to select it after opening the dialog. The tooltip tells how to use it. I believe it would be intuitive after trying it once.

I don't like the "Position Relative To..." dialog. The only reason for its existence would be the fact that now it may be impossible to snap to the anchor point of an item, the anchor of a footprint or the start point of a graphic line. With graphic lines it's clumsy because from the user's point of view both ends of a line are similar, but selecting it as the reference item in the dialog uses only the start point, which may not be what you want. So it works only for footprints or pads, and pads could already be covered with "Cursor location" because they can be snapped to.

[eelik (eelik)]

...and the Simple move.