Move/Rotate by Degrees - Is this how it should work?

[Anonymous]

Hello all,

I had a funny shaped part today and I was doing a lot of work in the "move" window.

It seems the measurements in the move window seem to be some strange mix of relative vs. absolute measurements depending on whether you are changing the last value you inputted or not.

Situation 1:

- Move x: 1in

- Change the x back to zero = the part moves back to it's original spot

This is okay - or at least, this is what I expect.

Situation 2:

- Move x: 1in

- Move y: 1in

- Go back and change x to 0 = the part doesn't move. It stays where it is (1 in off original position). You have to enter x: -1 and y:-1 in to get back to the original position. This behavior seems crazy to me. Just because I entered numbers in more than one line, it shouldn't suddenly change the move behavior.

It seems like it should be:

- Move x: 1in

- Move y: 1in

To go back to original position, enter 0 in in each.

It seems to be linked with how much text you have entered. The last number you entered, you can change, and it moves in an absolute manner (from the original position). If you enter numbers on several lines, and go back to alter them, it treats the parts current position as it's "zero point" - it begins to move relative to the position of the part.

So, in this manner, let's say a square has it's center point at 0,0

If you put x: 1 and y:1, the center point is now at 1,1

If you go back and enter x: 2 and y:2 the center point is now at 3,3

But if you are at 0,0

you put x:1, tab out or whatever and go back and change it to x: 2 (without putting in other values)the center point is at 2,0, in direct contradiction to the above method.

I created a screencast showing this.

Am I losing my mind? Am I wrong in thinking this is weird?

Thank you for any assistance.

[jeff_strater]

You are not losing your mind, @Anonymous.  .

To be honest, this behavior has to do with how we manage transactions within the software.  Move is split up into "steps" (an internal term).  A step changes when you a) change selection, or b) change the handle you are dragging.  To some extent, these boundaries are arbitrary, and so could be changed, but there is some justification.  In some cases, the sequences of operations are not order-independent.  For instance if you drag in x, then rotate about x, then drag in x again, those have to be done in that order, because the second drag in x is a different direction (because the rotation has re-aligned x).  So, when a step is started, we conceptually treat it as a new sub-operation.  If you drag the handles, we zero out the other numbers.  This is really intended to be the case when you are dragging the handles, and is important primarily when dealing with rotations.

I would say that what you show in the video (where you are just entering numbers in X, Y, and Z, not dragging handles, and not rotating) is a bug, and I'll file that bug.  Thanks for reporting it. 

Jeff

[jeff_strater]

Filed as FUS-25585