Good question. There is no technical barrier since it is possible to generate a mouse down event separate from a mouse up event however currently events are generated after the gesture is complete (meaning mouse location has been lost).
It’s easy to separate that into pre- and post- hooks, but the most reliable method I found for counting fingers in a gesture is “the maximum number of fingers during the gesture at any point” as it allows for variations in timing, location, direction, etc of first, second, subsequent fingers for a multi-finger gesture (you can’t assume they’re all present from the very start or that one finger won’t accidentally be raised mid-gesture). I’d have to change that to “detect number of fingers within xx ms of start of gesture” but that is somewhat problematic because the cursor position actually changes in response to touch between when your fist finger touched the trackpad and the time when (in your example) the third finger was finally added to the gesture (even if that all takes place in “a split second”). So it can be done but you might need to be intentional about being more careful with your three-finger swipe-to-drag to ensure the cursor remains within the desired click area until your third finger has made contact with the trackpad and hover there a brief moment to allow the daemon to determine you’re not going to add a fourth finger to the mix (changing it to another gesture altogether).
It would be entirely possible to retroactively generate a mouse down event at the original gesture start (with the first finger) when the third finger is added and no fourth finger is added, but that might be jarring from a UX perspective (cursor moves out of the bounding rectangle then the drag starts some ms later).
I had written a Windows script for adding three-finger drag[0] that I use daily, perhaps it could provide some inspiration.
Basically, it is an independent subscriber to RawInput messages that only keeps track of whether or not to send three-finger drag, and posts emulated mouse messages using SendInput. I have a few other scripts that each run as independent userland processes that only monitors their own trigger and nothing else.
Tangentially, my TPMouse[1] script implemented inertia in a framerate-independent way so that it uses very little resource while having perfect simulation stability.
A previous discussion where I explained the analytic derivation for this low-resource exact-solution damped inertia can be seen in [10]
It’s easy to separate that into pre- and post- hooks, but the most reliable method I found for counting fingers in a gesture is “the maximum number of fingers during the gesture at any point” as it allows for variations in timing, location, direction, etc of first, second, subsequent fingers for a multi-finger gesture (you can’t assume they’re all present from the very start or that one finger won’t accidentally be raised mid-gesture). I’d have to change that to “detect number of fingers within xx ms of start of gesture” but that is somewhat problematic because the cursor position actually changes in response to touch between when your fist finger touched the trackpad and the time when (in your example) the third finger was finally added to the gesture (even if that all takes place in “a split second”). So it can be done but you might need to be intentional about being more careful with your three-finger swipe-to-drag to ensure the cursor remains within the desired click area until your third finger has made contact with the trackpad and hover there a brief moment to allow the daemon to determine you’re not going to add a fourth finger to the mix (changing it to another gesture altogether).
It would be entirely possible to retroactively generate a mouse down event at the original gesture start (with the first finger) when the third finger is added and no fourth finger is added, but that might be jarring from a UX perspective (cursor moves out of the bounding rectangle then the drag starts some ms later).