WIP: Wayland kinetic scrolling

[sagarreddypatil]

Added kinetic scrolling by creating a event handler on a ms tick which emits mouse events starting after the AxisStop event is received from Wayland.

TODO:

• better stopping heuristics, currently it stops at inconvenient times. There's an unstable Wayland protocol for touchpad hold, but registering a handler seems to crash for some reason? Code is commented out
• Only doing kinetic scrolling when a touchpad is being used
• A proper velocity and decay calculation, I probably didn't look hard enough but I can't find the official way to do this
• Getting user settings for scroll speed and kinetic scroll decay
• Properly stopping when moving mouse across widgets (IIRC this isn't done on macOS either)

Not sure if having a timer for this is even a good idea, this is my first time doing anything Wayland

[cla-bot[bot]]

We require contributors to sign our Contributor License Agreement, and we don't have @sagarreddypatil on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'.

[sagarreddypatil]

@cla-bot check

[cla-bot[bot]]

The cla-bot has been summoned, and re-checked this pull request!

[furkanmustafa]

There is a potential problematic scenario with kinetic scrolls on Linux; where the scrollable view continues to scroll a bit more with the velocity gained by users action, AFTER the user has stopped scrolling.

Please read and decide yourself if this applies to your case. The scenario and explanation follows;

In MacOS, iOS, and such.. Scrollable views implement velocity natively on the scrollable view itself. It gains velocity, and keeps scrolling even after user stops the action, until the it stops by decelaration, Or until a brand new pan/scroll/tap/click event input.

In a lot of Linux desktop implementations, there are a lot of views to implement this for, and a lot of frameworks.. So instead of implementing this natively on views, main idea becomes resorting to emulating further input, in a decelarating fashion, after the user's actual input has stopped.

As far as I read from this PR, this seems very similar to the emulation case above.

In the emulation case, it might end up fine, as long as the care for following scenario has been taken care of;

• User starts scrolling, scroll gains a velocity
• User does not scroll any more, but the emulated input events keep going on for a bit more.
• User presses Ctrl (for a completely irrelevant action, but before the kinetic scroll stops)
• the decelerating emulated scroll input events get mixed up with the Ctrl press, and the whole UI suddenly goes into extreme zooming behavior (happens in browsers). Zooming, or whatever the Ctrl + scroll does for the application.

This unwanted behavior also comes with a huge performance penalty, because, changing the zoom level is usually quite compute hungry, for re-rendering everything again.

There could be several ways of avoiding such unwanted behavior. By ignoring "emulated" events in relevant places. Or by carefully checking long-press/long-scroll input timings.

I hope my information here is relevant. Please consider carefully.

Thanks.

[mikayla-maki]

As this PR hasn't had any work on it in 2 weeks, I'm going to close this for now. But feel free to re-open, pick up, or otherwise push this work forward. We'd still love to have this feature!