Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Ignore accidental window movements/grab ops #1482

Open
wants to merge 1 commit into
base: master_jammy
Choose a base branch
from

Conversation

michaelmob
Copy link
Contributor

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.

@@ -1396,6 +1407,7 @@ export class Ext extends Ecs.System<ExtEvent> {
/** Triggered when a grab operation has been started */
on_grab_start(meta: null | Meta.Window, op: any) {
if (!meta) return
this.grab_time = +new Date(); // timestamp
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 jacobgkau requested review from a team June 20, 2022 14:35
@jacobgkau jacobgkau self-assigned this Jun 20, 2022
@jacobgkau
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants