feat: Ignore accidental window movements/grab ops

[michaelmob]

Problem

Also mentioned in: #1287

A common problem I have is messing up my window tree by accidentally grabbing the titlebar of a window or by holding the super key and accidentally clicking anywhere on the window, dragging it. These accidental grabs/movements/re-positions of the window cause an instant reflow of the tree that can be disorienting and distracting focus from your main task.

https://user-images.githubusercontent.com/4530010/174450402-b7be9b72-35d0-4824-a7b3-fcea9bb9cabb.mp4

---

Solution

My preferred solution is to allow a small duration of time for the extension to ignore a window grab op/movement.

When we start a grab op, we set a current timestamp in the new grab_time property. When the grab op ends, that stored value is subtracted from the new current timestamp. If the result in milliseconds is less than the specified min_drag_ms then the op is set to null so the tree reflows back into position without being changed, essentially ignoring the window grab op/movement.

I don't know about you, but I know I'm not making precise window movement decisions in under 100ms. 100ms has worked so far for me and it could probably be as high as 200ms. I think 100ms is a good duration of buffer time for the autotiler to ignore an accident.

https://user-images.githubusercontent.com/4530010/174450413-3caded1a-5512-4459-a9c6-642cf896e2a4.mp4

---

Another lesser solution (not implemented)

Another solution is to compare the before and after window positions and determine if it has moved a far enough distance to warrant a tree change. This method would require a lot more logic. I consider this solution to be inferior to the paragraph above as High DPI mice/high resolution monitors would thwart this measure and we'd probably have to use percentages instead of pixels.

--

Work still in-progress? I haven't thoroughly tested this on any machine other than my own with GNOME 42.1. I'm very open to conversation and suggestions on the mechanics of this thing.

[jacobgkau]

A couple of observations:

• This does prevent some extremely quick movements from taking effect (that used to take effect before the change.)
• However, there are still some movements that are quick enough for the overlay to not show up, but slow enough to take effect.

https://user-images.githubusercontent.com/7199422/174653032-99432d96-e272-4e39-818e-8bf3979e6e5b.mp4

The delay between click/drag and the overlay showing up is already present in the currently-released version and is not a regression. This change has me wondering if the overlay should show up as soon as a click/drag would actually take effect. While 100ms is usually quicker than an intentional move, I can create false positives by e.g. flinging a window into a corner (especially with a non-touchpad mouse), and the fact that there's no visual feedback for when I've held down the button long enough could be considered confusing.