[mi4code]

Fixes #3179.

Grid uses input point to determine tile slot, which is wrong once touch is released because it fallbacks to mouse pointer point.

This changes it to use the currently previewed slot as the final.

Additionaly I changed the preview destroy animation to not resize since it led to showing random squares near the mouse pointer (both images after drag release; please ignore the smaller squares, it's background effect):

[ammen99]

his changes it to use the currently previewed slot as the final.

LGTM.

Additionaly I changed the preview destroy animation to not resize since it led to showing random squares near the mouse pointer (both images after drag release; please ignore the smaller squares, it's background effect):

The idea of this is that the slot preview should hide the way it was shown - expanding from the edge of the screen / wherever the pointer is. I definitely think we should keep that. I am a bit confused by the screenshots you have sent .. which of the squares are the previews?

I imagine that the issue could be that you move the mouse quickly after release and so the animation looks a bit arbitrary ending in the middle of the screen. Would it be any better if we forced it to be at the edge of the screen?

[mi4code]

The idea of this is that the slot preview should hide the way it was shown - expanding from the edge of the screen / wherever the pointer is. I definitely think we should keep that.

Yes, this works well and looks good with one exception:

• grab window with touchscreen and snap / drop it to an edge
• then there are no active touches, in that case the animation falls back to mouse pointer position
• as a result the preview gets animated to the point where mouse cursor is (which can be completely different from the previous touch position -> 1st image)

So I changed the preview animation when window is snaped and droped:

• window is snaped and droped (it will be resized to the size previewed)
• instead of shrinking it, the preview keeps its size and fades (no need to know where the last touch happened + I think it looks more logical)

(The commit message is bit misleading - I will change it.)

I imagine that the issue could be that you move the mouse quickly after release and so the animation looks a bit arbitrary ending in the middle of the screen. Would it be any better if we forced it to be at the edge of the screen?

This could work too, but I like keeping the preview size more.

I am a bit confused by the screenshots you have sent .. which of the squares are the previews?

1st image - preview is in the middle
2nd image - preview is on the left
(Both images show grid without my changes.)

[ammen99]

The idea of this is that the slot preview should hide the way it was shown - expanding from the edge of the screen / wherever the pointer is. I definitely think we should keep that.

Yes, this works well and looks good with one exception:

• grab window with touchscreen and snap / drop it to an edge
• then there are no active touches, in that case the animation falls back to mouse pointer position
• as a result the preview gets animated to the point where mouse cursor is (which can be completely different from the previous touch position -> 1st image)

So I changed the preview animation when window is snaped and droped:

• window is snaped and droped (it will be resized to the size previewed)
• instead of shrinking it, the preview keeps its size and fades (no need to know where the last touch happened + I think it looks more logical)

(The commit message is bit misleading - I will change it.)

I imagine that the issue could be that you move the mouse quickly after release and so the animation looks a bit arbitrary ending in the middle of the screen. Would it be any better if we forced it to be at the edge of the screen?

This could work too, but I like keeping the preview size more.

I am a bit confused by the screenshots you have sent .. which of the squares are the previews?

1st image - preview is in the middle 2nd image - preview is on the left (Both images show grid without my changes.)

Oh I see, yes, maybe the move plugin should simply feed the last input position correctly instead of relying on a heuristic? IIRC on drag done we get the correct release position, so if we feed that to grid, both issues here will be resolved?

[mi4code]

Yes, that would fix that too, except:

The preview would still shrink when the window is to be tiled, which doesnt make much sense to me.

Any plugin that will use grid to handle snap will need to cache the previous position - making grid guarantee to do what it shows seems to be cleaner to me.

[ammen99]

The preview would still shrink when the window is to be tiled, which doesnt make much sense to me.

Oh I see. Makes sense!

Any plugin that will use grid to handle snap will need to cache the previous position - making grid guarantee to do what it shows seems to be cleaner to me.

With the previous point, I finally understand the point of this PR 😅 So looking again it LGTM - if you have no further updates to make I'll proceed with merging.