Preliminary Snapping when Dragging and Dropping - II - The Search for a Pivot

OK, so I left you 1/2 updated about this, because I went for a swim.

The remaining difficulty was a thing which kept me stalled for quite a while, and it all came down to having used a convenient feature of Controls without realising this was going to have knock-on effects of other things I was doing...

OK, so the feature is Control.PivotOffset, which controls the point rotated around when you alter Rotation.  In previous work I set this to Control.Size / 2 so that the pivot was in the centre, so that when we hold rbutton and move the mouse, we can adjust the rotation in a natural way, rather than spinning around the top left corner.

What I hadn't realised, however, was that to work this must engage extra maths, which is processed every time the rotation or position is changed, and that this has a specific effect on the value returned from Control.GetTransform().  The transform returned is still a correct transform for the Control, but it does not reflect that the pivot has been changed.

Which means, when I naively started doing what I mentioned in my previous post and copying the transform out of the moving sheet at the start of dragging, everything worked exactly as I expected until I tried to rotate something.  When I applied rotations, the sheet moved as expected, but the overlay drawings of the moving snap-points rotated about a completely different point...

And it took me surprisingly long to get to grips with this, I could not at first work out why it was happening, let alone attempt to fix it.

There is a general point about API design illustrated by this, which I will get come back to at the end.

To cut a long story short, the problem is this.  In order to rotate about the pivot point, the control needs to effectively put its origin somewhere else.  Specifically. if we want the control to rotate about its centre, it needs to have its origin in the centre...  but this would have the side-effect of altering other calculations in addition to rotation.  If the origin were just moved, then the controls position would also be moved by PivotOffset, and its (unrotated) bounds would now be Position - Size/2 -> Position + Size/2, instead of being Position -> Position + Size.

Obviously the designers decided this would be too confusing to expose to the user, so they decided to conceal it, and write PivotOffset in such a way that Position remained unchanged, while still respecting the pivot.  I do not know the whole details of how they did this.  For rotation the basic thing they needed to do was adjust the origin every time it Rotation changes, and then put it back afterwards.  Basically the rotation needs to be applied on a different coordinate system than the control is usually represented in.  Specifically in this case:

• New transform = OldTransform.Translated(-PivotOffset).Rotated(delta_rotation).Translated(+PivotOffset)
• (Which is probably not literally how they do it, they may not ever store the transform as I don't think they'll have much of a use for it except when user code asks for it...)

Which makes the control work intuitively, it spins around the centre you expect, but it does mean that the transform returned from GetTransform (or GetGlobalTransform, in this case) no longer behaves quite the way you think: the transform has no idea about PivotOffset and any attempt to adjust Rotation inside the transform has a quite different effect from what rotating the control itself does.

((And there are further confusions here...  The control's position is no longer an unambiguous thing.  Why is that?  Well think about what happens when we have rotated the control.  Unrotated, position was at the controls top left, but where is it now?  To put it another way, when we undo the translation from PivotOffset after applying a rotation (as I sketched above) what axis system should that be in?

If we do that in the original axis system, then position will go back to where (in coordinates) it was, which is intuitive...  But where on the control is position located now?  Not at the corner of the rectangle which we used to label "top left", in fact, it is probably somewhere a little outside the rectangle altogether (see a random diagram off the internet that happens to show what I mean) so that's confusing.

But arguable, the other approach is even worse.  If we remove PivotOffset in the new axis system, then position will change as the control rotates.  It has to, because we are keeping position at the "top left" no matter what angle top left has been rotated to.

Godot seems to do the first, by the way, Control.Position does not change with Control.Rotation when Control.PivotOffset is set.  Possibly not a bad compromise in the circs...

--

But, to get back to the API design principle I mentioned earlier.  This is the sort of thing which happens when you attempt to conceal necessary complexity from the user.  (Unnecessary complexity is totally different, conceal away, or even better don't go there in the first place...)  If it has been me, when I saw that implementing PivotOffset required special code (by which I mean separate from normal Transform operations) I might have either:

1. accepted that this was going to alter the position of the control on screen, written that up in the docs OR
2. integrated the concept of PivotOffset into Transform2D so that *anything* (using a Transform2D) could have one

At least I might have done one of these, neither is perfect:  1. leaves me answering "what happened to my control position" questions on support forums forever and a day, while 2. looks nice, but means there will be N (or even N+1) bits of existing code which are unaware of PivotOffset when manipulating Transform2Ds, and which need hunting down and possibly fixing.

There are no perfect solutions, we just have to make a choice and live with it...

--

Anyway, my snapping?  Well this post got long, and there is something else to say, so I am going to say TBC, once more...