Depends on what "not worth it" means really. Even though gestures minus interactivity is far from how "proper" gestures feel, I'd rather have something rather than nothing (for example, it is still more convenient to 3-finger swipe to switch virtual desktop than a keyboard shortcut or clicking a button).
Ok, I admit that "not worth it" is better rephrased as "not the end goal". If the end goal is interactive gestures, one-off discrete gestures are welcome as an intermediate step or halfway solution.
Ideally the input framework would know if the streamed gesture was consumed real-time, and if not (e.g. no support for such interactice gesture in some program), the one-off event is issued.
This reminds me of current xorg libinput two finger scrolling / wheel event. Xinput2 is the relevant keyword but I am not sure exactly how it all fits in, only what I can observe:
- applications that don't know about multi finger scroll/pan listen for and accept classic mouse4 / mouse5 events and interpret them to scroll in steps if relevant. As an example, xev x event testing uility is not xinput2 aware AFAIK nor are classic x or older gtk programs
- applications can be xinput2-aware (e.g. eog Eye of Gnome image viewer, but maybe also any non-ancient gtk3 application as well), in which case they can scroll more directly (pixel-smooth) and with appropriate acceleration / smoothing / inertia (gtk-specific ?). In firefox there's an env var like MOZ_USE_XINPUT2 which tells firefox it can do this smoother wheel handling, not sure if it's required or automatic these days.
To test received events including xinput2, there is utility xinput --test-xi2
As a closing anecdote, there's an interesting interaction bug I have experienced with xfce where both xfwm will react to Super+scroll (compositor-level full screen zoom), and the application under the mouse pointer will also react to the scroll up/down. I have not deciphered the interactions here but it depends on app under mouse cursor...