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.

accidental.window.click.and.dragging.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.

prevented.accidental.window.movements.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.

[michaelmob]

Is this an appropriate way to get a timestamp in gjs?

I wanted to use this.grab_time = global.get_current_time(); but it only seems to return 0. Maybe it doesn't do what I think it does, couldn't find docs.

[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.

simplescreenrecorder-2022-06-20_11.28.38.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.