Inertial scrolling/Kinetic scrolling is missing in the Linux version

[westerlind]

Inertial scrolling is missing in the Linux version, while being available in the macOS version (as almost all apps there of course).

This is not as obvious of a feature on Linux as it is on macOS, but it is the default behaviour in Gnome these days, so with the focus on being GTK/Adwaita native, I think it does make a lot of sense to make this available at least as an option.

One example of a Gnome centric terminal that does support this is Ptyxis (which is the default terminal on Fedora since v41), and to me, that feature alone makes the general user experience of Ptyxis nicer than Ghostty at the moment, even though Ghostty is of course superior in many other ways.

Having been primarily a Mac user for many years, I have come to love the inertial scrolling behaviour, and I always strongly miss it where it isn't available.

[mitchellh]

I didn't realize GTK supported this. Can you point to any documentation on how we get inertial scrolling events? We manage inertial scrolling in the cross-platform libghostty core so it should just be a matter of sending libghostty the proper events from the GTK apprt.

Note that Ptyxis is GPL so do NOT link to any of its source code or use it to PR anything.

[jcollie]

A quick google turns this up: https://docs.gtk.org/gtk4/class.ScrolledWindow.html#touch-support

Not sure if that's what ptyxis is using.

[taoky]

Ptyxis uses VTE, and it sets enable-fallback-scrolling as false (https://gnome.pages.gitlab.gnome.org/vte/gtk4/property.Terminal.enable-fallback-scrolling.html) and scroll-unit-is-pixels as true (https://gnome.pages.gitlab.gnome.org/vte/gtk4/property.Terminal.scroll-unit-is-pixels.html) to support inertial scrolling.

(This could be tested with GTK inspector (GTK_DEBUG=interactive))

[westerlind]

GTK seems to call it kinetic scrolling rather than intertial scrolling, but it's the same thing.

https://docs.gtk.org/gtk4/property.ScrolledWindow.kinetic-scrolling.html

[jcollie]

Given that this needs a ScrolledWindow we probably might as well implement a scroll bar as well if someone implements this.

[westerlind]

I would for sure appreciate a scrollbar too, but I guess that doing it this way might have other downsides that we don't wont, like not being able to have inertial scrolling for terminal apps for example, and I guess it would change the structure of things quite a bit.

One alternative way of doing it would be to calculate the intertial scrolling in Ghostty instead (which I guess is what GTK simply helps apps doing when they use ScrolledWindow, as it doesn't seem to be done on the OS level the way it is in macOS), and base it on something like the following simple description of how Apple calculated the inertial scrolling in an unofficial Javascript library they seem to have made a long time ago. Not necessarily the exact same numbers as what GTK is using, so the numbers should possibly be slightly different, but the calculation needed to make it work well does not seem to be all that complex based on this anyway.

https://stackoverflow.com/questions/38619717/need-help-dissecting-and-recreating-the-perfect-scroll-easing-based-on-pastrykit

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.

[westerlind]

Is it maybe reasonable to implement this in a similar way as the proof-of-concept for a solution for a scrollbar on macOS here: #111 (comment) (maybe that was what you meant previously @jcollie?)

My understanding is that this would mean creating a ScrolledWindow that hosts the actual Ghostty terminal view, which "thinks" that it's scrolling the terminal content even though it isn't actually doing that, but because it behaves the same way weather it actually scrolls the content or not, that can be used to get the kinetic-scrolling events, and probably also to render the scrollbars.

My understanding is that Ptyxis is doing this by actually letting ScrolledWindow scroll the terminal content, and then they get both the scrollbar and the kinetic scrolling without having to do all that much more, but I guess that it would probably be possible to do it as described above too, and to me that seems like a better fit for Ghostty?

If I understand #2524 (comment) and #111 right, the plan is to do it this way on macOS for the scrollbar, so then it would make sense to structure it the same way on GTK too for the scrollbar and kinetic scrolling.

[pluiedev]

Please reread our discussion rules - no bump comments please!