System wide inertial / kinetic scrolling and rubber banding

Hello,

thank you for developing the cosmic desktop, I'm pretty impressed so far.

Are you planning to support system wide inertial / kinetic scrolling and rubber banding for touchpad events?

Here is an illustration of what I mean, in the front, you see the default behaviour for Apps on linux, in the background there is Firefox with kinetic scrolling enabled, which feels way more natural.

I would love to see this implemented in the Compositor / OS Layer. That's how it is implemented in macOS and it prevents putting too much effort for this on the App developers. It also prevents having different behaviour in different apps because of an app specific implementation...

BTW there is an open source JavaScript implementation by Apple called PastryKit using a magic number momentum * 0.95.

> I am trying to find out the easings/formulas they use and logical conditions they use them in. Apple has a crazy way of writing confusing JS, so even tho i am a full stack developer, i am having a hard time tracing everything down. And i figured few brains is better than one, so lets see, does anyone understand this file? :D > https://github.com/jimeh/PastryKit/blob/master/mobile/dist/PastryKit.js > IN SHORT (so there are no misunderstandings): I am trying to extract a set of physics rules from this file, which i can use as guidelines in order to write my own implementation of scroll on any platform i choose. :) > for example: 'normal' scroll is defined by {>300ms && >10px}, apple uses the following bezier curve when easing the animation of slowdown. cubic-bezier.com/#.25,.46,.1,.94 > UPDATE: We solved this a while ago. We discovered how Apple does it's momentum. https://medium.com/homullus/recreating-native-ios-scroll-and-momentum-2906d0d711ad > After many hours of dissecting the algorithm, we concluded that Apple is in fact using magic numbers. And the magic number is: (drumroll) `momentum * 0.95`. > Basically, while the touch lasts, apple lets you move the screen 1:1. > On touch end Apple would get momentum by dividing number of pixels that the user had swiped, and time that the user has swiped for. If the number of pixels was less than 10 or time was less than 0.5, momentum would be clamped to zero. > Anyways, once the momentum (speed) was known to us, they would multiply it by 0.95 in every frame, and then move the screen by that much. > So idiotically simple and elegant, that it hurts. :)

Since this might be a bit tricky to solve, I would at least implement the following options:

enable / disable kinetic scrolling completely
a speed option to control how fast and far the scrolling goes

There is a very detailed discussion over on AvaloniaUI, where I go more into detail and a very helpful response from a very experienced developer.

pop-os / cosmic

System wide inertial / kinetic scrolling and rubber banding #408