5 ms·

It isn't... You can see this in an open source JavaScript implementation of kinetic scrolling by Apple called PastryKit[3] using a magic number momentum * 0.9.

It isn't... You can see this in an open source JavaScript implementation of kinetic scrolling by Apple called PastryKit[3] using a magic number momentum * 0.9. The problem is, that on modern Linux environments, there is no clear responsibility for where scroll handling code belongs. Especially Kinetic / Inertial scrolling is handled way different than in macOS. There is libinput (for handling and redirecting input events) There is the display server There is the compositor There is the window manager There is the app layer (every App, like Firefox, Gimp, Currently kinetic scrolling is implemented on the App layer, every app has to handle the scrolling events manually to provide kinetic scrolling. This is not the case in macOS... the kinetic scrolling / rubber banding is handled within the OS. In my opinion, the scrolling code could belong into the compositor, so that not every app developer has to write code to handle the scrolling, but still prevent unwanted effects like kinetic scrolling transfer between windows. Additionally, the kinetic scrolling approach is not configurable in Gnome... some touchpads / screens are scrolling way to fast, some are too slow... I filed an issue[1] on cosmic in hope they'll get it right, but I don't have too high hopes that this is of much interest. On Fedora it works ok-ish with a little hack[2] called libinput-config. [1]: https://github.com/pop-os/cosmic-epoch/issues/204 https://github.com/pop-os/cosmic-epoch/issues/204 [2]: https://gitlab.com/warningnonpotablewater/libinput-config.git https://gitlab.com/warningnonpotablewater/libinput-config.gi... [3]: https://stackoverflow.com/questions/38619717/need-help-dissecting-and-recreating-the-perfect-scroll-easing-based-on-pastrykit https://stackoverflow.com/questions/38619717/need-help-disse...

tannhaeuser 3y ago
Worth mentioning that before libinput, the synapse driver handled kinetic scroll very well IMO, but AIU the developers removed the device-specific coefficients and other parameters because they said it couldn't be tested and became a mess or something. I remember looking at my Linux (Wayland, gnome3) notebook in anticipation of physical pain, at which point I switched to Mac OS permanently. To this date, I still don't understand why Linux desktop developers had to throw everything away and valued their grand refactorings more than a working desktop, especially when absolutely no new desktop apps are being developed anyway, but I guess that's what you get with a "hobby" (= developer motivation rather than demand driven) OS after all.
- sandreas 3y ago
  While is may be true from a user perspective, this "kinetic scrolling simulation" was removed, because it could lead to unexpected behaviour. Example: If you where scrolling in a window, the driver kept sending scroll events for a short time to simulate kinetic scrolling. Now, if you moved the cursor to another window, the other window started scrolling, because of the simulated events. This is not the case on macOS. Changing window focus doesn't change the scrolling. So, while working from a user perspective (in my opionion this would have been better, than NO kinetic scrolling at all), technically, it is a bug / unsolvable behaviour :-), because this problem cannot be solved on the driver level - there is no reference to the current focussed "window" / active element. That's probably the reason why they thought: This must be solved at App level, which was the worst decision they could make. Putting the effort on the shoulders of App developers instead of solving it at one place leads to so much wasted developer time, that could have been put into new features or solved issues. I was shocked about how nobody seemed to notice that. However, they are not "hobby" at all. Peter Hutterer is awesome and he understands the problem very well - but as a single developer it's hard to convince a whole community, that partly does not even (want to) understand the problem. And he's responsible for libinput, not for the compositors - so it's clearly not his fault. I think the problem lies in separated responsibilities. They are trying to keep the projects (driver, compositor, window manager) separated / independent, but in this case, the problem is spanning the whole stack.
  - jmole 3y ago
    > Now, if you moved the cursor to another window, the other window started scrolling, because of the simulated events. This is such a trivial thing to fix, you just stop sending scroll events when the cursor moves. Peter has done a great job on libinput for the most part, but he is 100% wrong about inertial scrolling (and button remapping, among a few other things).
    - sandreas 3y ago
      > Peter has done a great job on libinput for the most part, but he is 100% wrong about inertial scrolling (and button remapping, among a few other things). Maybe you're right. However, this should not about individual persons / projects... this is more about that I'm still uncertain, why so many experts cannot get this thing right by just working together finding a suitable solution :-) There must by more than one way of solving this. I'd argue that he is right about the fact, that the "driver" (libinput) should not send "simulated" events, that are not really there. Whereas the cursor movement should defintely stop the scrolling behaviour, the driver is not the place to care about this, I think it is more a compositor / window manager thing, but I'm not an expert. However, if he would implement an opt in solution (2 config options) for lets say: libinput.simulateKineticScrolling=1 libinput.kineticScrollingSpeed=0.22 a lot of people would be really happy, but this probably is a really dirty hack.
yencabulator 3y ago
> There is the display server > There is the compositor > There is the window manager What kind of Schrodinger Way11 world is that? X11 has display server and window manager (and window manager doesn't deal with mouse movement), and Wayland has a compositor.
- sandreas 3y ago
  I just meant to point out the complexity of the transition Linux has gone through... The transition from X11 to Wayland is still a thing and most Environments / Window Managers still use code from both technologies. However, you are right, there is no such thing like display server AND compositor. > and window manager doesn't deal with mouse movement And that's causing one of the problems I described above, when changing window focus while scrolling. The driver just sends scrolling events, regardless of the window focus, so it keeps scrolling, when you trying to "simulate" kinetic scrolling.
ralphist 3y ago
> I filed an issue[1] on cosmic in hope they'll get it right, but I don't have too high hopes that this is of much interest. That's insane but you're right. Firefox on Ubuntu had awful trackpad scrolling 10 years ago and it's still bad. How do you make an OS where the main pointing device on half of the market sucks and assign that low priority?
- pmontra 3y ago
  I've been using Firefox on Ubuntu from 2009 to 2022, 08.10 to 22.04, then switched to Debian, but I never noticed any problem. I always used X11, a laptop, touchpad and two finger scrolling. Maybe is it a Wayland thing? Or it is very subjective.
  - bmicraft 3y ago
    Try enabling "XINPUT2" in firefox, you'd be surprised what a difference it makes
    - pmontra 3y ago
      I gave it a try. The difference is that XINPUT2 scroll has inertia: I start scrolling, remove the fingers from the touchpad and it keeps scrolling for a while. If I want to stop when I see something interesting I have to click or it will scroll away. That adds an extra action that must performed at the right time. I don't think I like that because this is not a videogame and Firefox is not supposed to challenge my abilities. I prefer the current behavior: it scrolls until I stop sliding my fingers on the touchpad. Then I have to move them up to the top of the touch pad and start again but I can scroll all the front page of HN in a single motion and it gives me time to check what I'm looking at, especially on longer pages (this comment thread.) Anyway, it's nice to have different settings that suit different people.
      - bmicraft 3y ago
        > I start scrolling, remove the fingers from the touchpad and it keeps scrolling for a while If you want it to not scroll further you need to stop scrolling before lifting you fingers. That should be pretty easy to get used to.
ben-schaaf 3y ago
Slight correction: macOS handles the kinetic scrolling, but rubber banding is handled by the app itself.
- sandreas 3y ago
  Oh, that was new to me. Thanks...
culopatin 3y ago
This explains a lot. Thanks so much! This is a rabbit hole I didn’t want to go in a few years back. Some people would say they had issues, others didn’t. Would’ve taken me a lot of time to figure out that we all may be talking about different DEs, apps, etc.

tannhaeuser 3y ago

Worth mentioning that before libinput, the synapse driver handled kinetic scroll very well IMO, but AIU the developers removed the device-specific coefficients and other parameters because they said it couldn't be tested and became a mess or something. I remember looking at my Linux (Wayland, gnome3) notebook in anticipation of physical pain, at which point I switched to Mac OS permanently. To this date, I still don't understand why Linux desktop developers had to throw everything away and valued their grand refactorings more than a working desktop, especially when absolutely no new desktop apps are being developed anyway, but I guess that's what you get with a "hobby" (= developer motivation rather than demand driven) OS after all.

sandreas 3y ago
While is may be true from a user perspective, this "kinetic scrolling simulation" was removed, because it could lead to unexpected behaviour. Example: If you where scrolling in a window, the driver kept sending scroll events for a short time to simulate kinetic scrolling. Now, if you moved the cursor to another window, the other window started scrolling, because of the simulated events. This is not the case on macOS. Changing window focus doesn't change the scrolling. So, while working from a user perspective (in my opionion this would have been better, than NO kinetic scrolling at all), technically, it is a bug / unsolvable behaviour :-), because this problem cannot be solved on the driver level - there is no reference to the current focussed "window" / active element. That's probably the reason why they thought: This must be solved at App level, which was the worst decision they could make. Putting the effort on the shoulders of App developers instead of solving it at one place leads to so much wasted developer time, that could have been put into new features or solved issues. I was shocked about how nobody seemed to notice that. However, they are not "hobby" at all. Peter Hutterer is awesome and he understands the problem very well - but as a single developer it's hard to convince a whole community, that partly does not even (want to) understand the problem. And he's responsible for libinput, not for the compositors - so it's clearly not his fault. I think the problem lies in separated responsibilities. They are trying to keep the projects (driver, compositor, window manager) separated / independent, but in this case, the problem is spanning the whole stack.
- jmole 3y ago
  > Now, if you moved the cursor to another window, the other window started scrolling, because of the simulated events. This is such a trivial thing to fix, you just stop sending scroll events when the cursor moves. Peter has done a great job on libinput for the most part, but he is 100% wrong about inertial scrolling (and button remapping, among a few other things).
  - sandreas 3y ago
    > Peter has done a great job on libinput for the most part, but he is 100% wrong about inertial scrolling (and button remapping, among a few other things). Maybe you're right. However, this should not about individual persons / projects... this is more about that I'm still uncertain, why so many experts cannot get this thing right by just working together finding a suitable solution :-) There must by more than one way of solving this. I'd argue that he is right about the fact, that the "driver" (libinput) should not send "simulated" events, that are not really there. Whereas the cursor movement should defintely stop the scrolling behaviour, the driver is not the place to care about this, I think it is more a compositor / window manager thing, but I'm not an expert. However, if he would implement an opt in solution (2 config options) for lets say: libinput.simulateKineticScrolling=1 libinput.kineticScrollingSpeed=0.22 a lot of people would be really happy, but this probably is a really dirty hack.

yencabulator 3y ago

> There is the display server > There is the compositor > There is the window manager What kind of Schrodinger Way11 world is that? X11 has display server and window manager (and window manager doesn't deal with mouse movement), and Wayland has a compositor.

sandreas 3y ago
I just meant to point out the complexity of the transition Linux has gone through... The transition from X11 to Wayland is still a thing and most Environments / Window Managers still use code from both technologies. However, you are right, there is no such thing like display server AND compositor. > and window manager doesn't deal with mouse movement And that's causing one of the problems I described above, when changing window focus while scrolling. The driver just sends scrolling events, regardless of the window focus, so it keeps scrolling, when you trying to "simulate" kinetic scrolling.

ralphist 3y ago

> I filed an issue[1] on cosmic in hope they'll get it right, but I don't have too high hopes that this is of much interest. That's insane but you're right. Firefox on Ubuntu had awful trackpad scrolling 10 years ago and it's still bad. How do you make an OS where the main pointing device on half of the market sucks and assign that low priority?

pmontra 3y ago
I've been using Firefox on Ubuntu from 2009 to 2022, 08.10 to 22.04, then switched to Debian, but I never noticed any problem. I always used X11, a laptop, touchpad and two finger scrolling. Maybe is it a Wayland thing? Or it is very subjective.
- bmicraft 3y ago
  Try enabling "XINPUT2" in firefox, you'd be surprised what a difference it makes
  - pmontra 3y ago
    I gave it a try. The difference is that XINPUT2 scroll has inertia: I start scrolling, remove the fingers from the touchpad and it keeps scrolling for a while. If I want to stop when I see something interesting I have to click or it will scroll away. That adds an extra action that must performed at the right time. I don't think I like that because this is not a videogame and Firefox is not supposed to challenge my abilities. I prefer the current behavior: it scrolls until I stop sliding my fingers on the touchpad. Then I have to move them up to the top of the touch pad and start again but I can scroll all the front page of HN in a single motion and it gives me time to check what I'm looking at, especially on longer pages (this comment thread.) Anyway, it's nice to have different settings that suit different people.
    - bmicraft 3y ago
      > I start scrolling, remove the fingers from the touchpad and it keeps scrolling for a while If you want it to not scroll further you need to stop scrolling before lifting you fingers. That should be pretty easy to get used to.

ben-schaaf 3y ago

Slight correction: macOS handles the kinetic scrolling, but rubber banding is handled by the app itself.

sandreas 3y ago
Oh, that was new to me. Thanks...

culopatin 3y ago

This explains a lot. Thanks so much! This is a rabbit hole I didn’t want to go in a few years back. Some people would say they had issues, others didn’t. Would’ve taken me a lot of time to figure out that we all may be talking about different DEs, apps, etc.