Multitouch-Community icon indicating copy to clipboard operation
Multitouch-Community copied to clipboard

Tap to middle click + modifier key

Open jdpurcell opened this issue 2 years ago • 5 comments

I have these actions configured: image

I noticed that if I want to hold Cmd and three finger tap, the receiving app only gets the middle click with no modifier keys. I tried the same thing using your "Middle" app instead and it worked fine. Switching back to Multitouch, for some reason I thought to try three finger click and that actually passed through the modifier as well! So it's just a problem on the tap action. Interestingly, if I Cmd+three finger click, then any subsequent three finger taps all report the Cmd modifier even though the key is no longer held down. So it kind of seems like three finger tap is already trying to handle the modifiers but it forgets to capture the current keyboard state before sending off the event.

jdpurcell avatar Oct 01 '23 00:10 jdpurcell

Thanks for reporting. I'll see what I can do in an upcoming release.

rxhanson avatar Oct 02 '23 19:10 rxhanson

I would still appreciate if this could be fixed if it's not too much trouble. The use case, in case you're curious or want an app to test with, is a fork of an image viewer I maintain, that provides the ability to customize various mouse actions. This allows, for example, different zoom/fit actions to occur depending on whether the command key is held along with middle click.

Screenshot 2024-02-10 at 12 48 22 PM

jdpurcell avatar Feb 10 '24 17:02 jdpurcell

Thanks for following up on this, and apologies for losing track of this one.

I made a quick build with a fix that should work for you, but I haven't had a chance to test it.

https://www.multitouch.app/downloads/multitouch1.27.27.dmg

You'll have to enable this functionality with this terminal command:

defaults write com.brassmonkery.Multitouch clickModifierPassThrough -int 1

Then restart the app if it's running.

The reason to not have this enabled by default on Multitouch is because it causes ambiguity with gestures that the user might have configured with a modifier key restriction, or if the action is something like cmd+click, then it's not clear if the user wants to include other held modifier keys or not. I'll give this some more thought and see if I want to change the default behavior.

rxhanson avatar Feb 11 '24 05:02 rxhanson

I just tried it out, and it seems to be working as expected! I appreciate it 👍

jdpurcell avatar Feb 11 '24 06:02 jdpurcell

I thought about it as well; here's what makes sense to me, in case it helps you decide.

Restrictions:

  • Matching: Two-pass approach, such that if modifier keys are currently held, look for a gesture defined with those EXACT modifier restrictions. Only if no match was found, look for a gesture with no modifier restrictions defined. I believe this is how it already works, in which case, no changes suggested.
  • Pass-Through: If matched via a modifier restriction, the modifier is only considered to be part of the restriction, i.e. it does not indicate additional user intent, and no pass-through shall occur. If the gesture has no modifier restrictions, pass through the currently held modifier keys.

Actions:

  • If, based on the previous logic, a pass-through would occur, but the action itself invokes a modifier, this could either bypass pass-through mode, or pass through by combining the held modifier keys somehow (e.g. OR/XOR). If the combination thing is tricky to implement, keep it simple and bypass pass-through, otherwise the OR approach seems fine.

jdpurcell avatar Feb 11 '24 16:02 jdpurcell