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

Reset warp lock after first motion #36

Closed
wants to merge 1 commit into from
Closed

Reset warp lock after first motion #36

wants to merge 1 commit into from

Conversation

acrisci
Copy link

@acrisci acrisci commented Jul 17, 2015

Reset has_warp to false (after it has been set after a successful
warp) when the next motion is received.

This should still prevent the cursor "looping" when warping, while
preventing the cursor from getting "stuck" in torus mode.

fixes #35

Reset `has_warp` to false (after it has been set after a successful
warp) when the next motion is received.

This should still prevent the cursor "looping" when warping, while
preventing the cursor from getting "stuck" in torus mode.

fixes #35
@acrisci
Copy link
Author

acrisci commented Jul 17, 2015

Especially, consider this scenario:

       +---+
 +---+ | 3 |
 | 1 +-+-+-+
 +---+ 2 |
     +---+

Imagine hitting the upper right edge of 1 (moving from left to right) without the current fix. You'd instantly end up on 3 because you warp from 1 to 2 as expected, but then also from the top edge of 2 to 3.

This doesn't address this issue, but I think it's more natural to go from 1 to 3 in this case.

@Airblader
Copy link
Owner

I'm not really happy with this. I get a lot of really weird twitches if I happen to move the cursor in a straight line, even in a standard use case screen setup.

+---+
| 1 |---+
+---+ 2 |
    +---+

Moving from left to right in the upper area in a straight line causes the correct warp to 2, but continuing to move the cursor makes it warp continuously between the top and bottom edge, which is really twitchy.

@Airblader
Copy link
Owner

What do you think about using a very short "timeout"? If the mouse stays still for a bit, we reset the flag.This would both allow continous movement as in my case and solve your problem if I understand it correctly, right?

@acrisci
Copy link
Author

acrisci commented Jul 17, 2015

I'm not really happy with this. I get a lot of really weird twitches if I happen to move the cursor in a straight line, even in a standard use case screen setup.

I'm not seeing this on my end.

What do you think about using a very short "timeout"?

I'm not really into this. Maybe I'll think of something else.

@Airblader
Copy link
Owner

I'm not seeing this on my end.

Reproduce like this:

xedgewarp -t both -o "200x200+0+0,200x200+200+100" &
sleep 1; xdotool mousemove 150 50; sleep 1; for i in {1..150}; do xdotool mousemove_relative 1 0 && sleep 0.05; done
killall xedgewarp

@Airblader
Copy link
Owner

I'm going to close this PR for now. If we can come up with a different way to overcome this, we can open a new PR, but this solution is not what I want to merge.

@Airblader Airblader closed this Aug 8, 2015
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.

Torus mode - mouse gets stuck
2 participants