MouseDef icon indicating copy to clipboard operation
MouseDef copied to clipboard

Application shortcuts containing ⌘ and ⇧/fn continues action

Open vladdeSV opened this issue 5 years ago • 9 comments

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 avatar May 30 '20 21:05 vladdeSV

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 avatar May 30 '20 21:05 vladdeSV

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 avatar Jun 01 '20 14:06 vladdeSV

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.

vladdeSV avatar Jul 24 '20 08:07 vladdeSV

@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 avatar Jul 24 '20 09:07 zenangst

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 avatar Jul 24 '20 09:07 zenangst

I made a PR for this here #10

zenangst avatar Jul 24 '20 09:07 zenangst

Here is a version that you can test with:

MouseDef.zip

zenangst avatar Jul 24 '20 09:07 zenangst

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 avatar Jul 24 '20 10:07 vladdeSV

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

vladdeSV avatar Jul 30 '20 08:07 vladdeSV