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

Application shortcuts containing ⌘ and ⇧/fn continues action #8

Open
vladdeSV opened this issue May 30, 2020 · 9 comments
Open

Comments

@vladdeSV
Copy link
Contributor

vladdeSV commented May 30, 2020

When issuing a shortcut command (either system wide or application specific) MouseDef gets locked in the action.

For instance, the system wide shortcut to take a screenshot 4 causes MouseDef to snap into resizing mode when the keys are not being pressed. Pressing and releasing the again stops the resizing action.

screenshot example

@vladdeSV
Copy link
Contributor Author

vladdeSV commented May 30, 2020

I have experienced once where using an application shortcut containing and fn was locked in the "moving window" action, requiring to restart MouseDef.

However, I do not remember what I did to do this. Will post an update once I can reliably reproduce the problem.

@vladdeSV
Copy link
Contributor Author

vladdeSV commented Jun 1, 2020

I cannot reproduce MouseDef getting stuck in a resize/reposition state and requiring shutting down the app. So far the example in the GIF is all I have as of now.

@vladdeSV
Copy link
Contributor Author

One idea might be to not start moving/resizing the window until the cursor has been moved.

For instance, when I take a screenshot with 4 I am holding , but since I am not moving the cursor I would not know if the program is actively resizing it the window or not.

By not moving/resizing until the cursor is moved, then this problem should go away.

@zenangst
Copy link
Owner

@vladdeSV Currently investigating the approach that you are suggesting. I'm wondering how we could monitor both, or rather we do that today but the trigger for the function to be invoked is that the flag modifiers change and then we wait for the mouse position to change in order to move or resize windows. I don't want to constantly monitor the mouse position based on movement but maybe it should monitor that way. It would mean that we would have to write some of the logic but it might just be what we want. I'll do some more digging to see what I can come up with, there might be an easier way to do this that I'm not seeing right now.

@zenangst
Copy link
Owner

I think I came up with a very minor but doable fix now.
Instead of simply monitoring flags changed, we now check for .keyUp and keyDown events.
What this means is that we would simply cancel the resize or move invocation if the user presses a key while having the modifiers pressed. That would mean that it would start to resize when you tap but as soon as 4 gets pressed it would cancel the current resize session.

I've done some minor testing and it seems to be working, the nice thing about this change is also that it gets rid of the locked in effect where move or resize can get stuck.

What do you think @vladdeSV ?

@zenangst
Copy link
Owner

I made a PR for this here #10

@zenangst
Copy link
Owner

Here is a version that you can test with:

MouseDef.zip

@vladdeSV
Copy link
Contributor Author

Here is a version that you can test with:

MouseDef.zip

Awesome, I'll try it out next week when I'm back at my mac!

@vladdeSV
Copy link
Contributor Author

I did some testing, and the issue still remains with the new binary 😞

However, I did notice that the resizing stopped as soon as I pressed another key, and not like previously where I had to press again to make it stop.

still stuck

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

No branches or pull requests

2 participants