Inertial scrolling support #4175
Comments
It's something that doesn't make much sense in a terminal emulator, since all scrolling is discrete, however such scrolling is contiguous.
No.
For long output you have PageUp/PageDown, and a lot of other special actions in Vi mode to scroll the output faster. You also has an option to increase scroll speed (in a config) or move your mouse out side of the window in a direction you're scrolling to trigger auto scroll, which is pretty fast. |
... That was quite rude and honestly uncalled for, but if that is your decision then I guess this request is closed. |
I gave an explanation one sentence above why it doesn't make sense, but I didn't close an issue in a first place, since there could be other opinions other than my own, on so called 'smooth scrolling' thing. I'm ot sure how providing explanation and saying 'no' based on that is considered 'rude', I've also suggested alternatives to scroll faster. This 'feature' was already brought in the past here And the response for it is there, and I absolutely agree with it, since in terminals scrolling is discrete by design. One more issue that some systems do that on a system level, and so it can't be in alacritty, but it could be somewhere else, like in a windowing library we're using, so for us it'll be transparent. |
macOS does it on a system level AFAIK. But that doesn't stop Firefox from implementing inertial scrolling for Linux. And so the fact that some systems do it doesn't mean alacritty can't do it for other systems...
Just to clarify, this request is NOT for smooth scrolling. This is for inertial/"kinetic" scrolling. The point is not to be smooth and seamless between lines, it's to allow flicks.
It's rude to say, this is unnecessary and makes no sense, there are already so many methods to do what you want, we are a terminal this does not belong here. |
How do you know that system Z doesn't do that on driver level level in e.g. alacritty, we can assume that it's on a driver level in macOS, but what about the rest? I don't see any reason for it to be here, if anything it could be in winit or something like that, so it can handle it for each platform. |
You have config options for select to clipboard and everything already... why not have inertial/kinetic scrolling be a config option too? Hell, maybe add scrolling speed/friction settings too while you're at it. It could even be disabled by default, I wouldn't care.
Why would it be there? Why should the terminal not handle scrolling in the terminal? |
Because we have little information about the driver we're using? We just get 'scroll' events from winit, everything that must be done for kinetic scrolling is in winit, in alacritty the only thing we can do is to multiply it somehow and do in a way it was done in a proposed patch. We can't even have it auto enabled by default since it's driver dependent on even X11(yes, some drivers on X11 do kinetic scrolling by default and it causes applications to scroll act very weird due to that), so it must be disabled, but you can't even truly disable, since in some cases it comes from driver...
You can adjust the speed of scrolling right here . Scrolls pretty fast with huge values. |
|
Some refs if someone decide to read into implications. https://wayland.freedesktop.org/libinput/doc/1.11.3/faq.html#faq_kinetic_scrolling |
That's why I said "It could even be disabled by default, I wouldn't care."
Yes, I'm aware of the old synaptics driver as well.
You would be disabling alacritty's kinetic scrolling, but you don't have to guarantee that it will wipe all kinetic scrolling from your system. Honestly, that whole section that tries to make it sound like this is a headache, doesn't really add much. Your first paragraph is a bit stronger in that regard.
speed/friction, if you already have speed, still friction (rate at which the scroll slows down). |
I'm aware of the problems of implementing kinetic scrolling in the driver (which is not applicable here btw). That's why I say in my original post that applications need to support it explicitly... Firefox does have kinetic scrolling when you enable xinput2, which in my case both allows pixel-perfect scrolling (yay, but not applicable to alacritty) and kinetic scrolling. I suppose that would be proof enough that if even Firefox can't pull it off without, alacritty would need to depend on such a specific driver(/protocol?) as well. This would become a "kinetic scrolling is implemented for xinput2" situation. But I don't see much problem with that, please let me know if that kind of optional dependency is an issue. edit: I believe xinput2 is actually a protocol that's used by multiple drivers, so that would be less of a painful situation than trying to support every single driver individually. |
|
As I've stated in the closed #3379, I personally feel like my scrolling should be consistent across applications. This implies the setting should be at the system level, not the application level. I would find it strange to have some applications scrolling with inertia, while others do not. If there are changes to winit/glutin to support this I would be completely in favor of updating Alacritty to use these settings, though I would personally have it disabled. I do wonder how this relates to touchscreen scrolling, since that I might expect to allow "flicking" to scroll with inertia. |
|
As stated in #3379 (comment) and in this discussion, this is not something that should ever be implemented in Alacritty. I also agree with @nixpulvis that ideally this would be a system thing, otherwise you just get different behavior in every application which is garbage. I don't personally care much about kinetic scrolling since it's quite bothersome, but I don't see why we wouldn't have an issue around to at least track its status for potential upstream implementation in winit. |
|
It's not possible with the way X11 currently works to implement inertial scrolling at a system level. X11 only knows about the bitmaps of each application and sending inertial scrolling events at the system level would require a deeper understanding of what in the application a user is scrolling. Unfortunately the next best thing (continuing to send scroll events at the cursor to simulate inertia) has been tried before with the legacy synaptics driver and it kind of failed because X11 was not designed for this. Maybe Wayland could support this, I have no idea. But I doubt it, and complaining about how "the system doesn't support it therefore we shouldn't" isn't going to make the system support it. This is how it is, this is how Linux works right now, and you either implement this feature or you don't. That's the situation right now. I know it's not ideal to have to implement inertial scrolling in each application. The point of this feature request is not to argue over that. I'm aware that it's a sad situation that each application has to have their own inertial scrolling. But again, complaining will not change things. Also what the heck can winit do? They send scroll events, that's all you need. Trying to shove this onto winit is not okay imho because winit is not the GUI, winit is just the window. You implement the UI therefore this is squarely your problem. Whether or not you choose to deal with the problem is what we are debating here; not whether or not you can shove it onto someone else, or complain about how this situation isn't ideal. |
|
And yes, there are much more important things to do than this. I'm not being vocal because I want this right now. I'm being vocal because can only be implemented in alacritty, not anywhere else, and for some reason you are not okay with that. |
Wayland says that clients should implement kinetic scrolling, which is very clear.
Winit is a windowing toolkit, winit can generate synthetic scroll events like it does for key events already on X11. Winit can do more, since it has direct handling of scrolling from system, not limited API like we have in alacritty. So, nothing stops it from doing so. If they don't want such thing to be implemented, we can reiterate it here. |
|
Getting winit to implement inertial scrolling would be an endeavor for sure, because it would need to be able to support both, with you declaring whether or not a certain motion should be considered "inertial/kinetic" at the time of the event, and possibly in applications with changing UIs, independent of cursor position (give each motion an ID and relate events to that ID rather than the position of the cursor?). If winit is the one with access to the APIs, then you may be right that they are the only ones who can implement this. They just need to do it in a way that lets applications handle it themselves; not the naive way of just sending events to the same cursor position (which is what I thought you meant). |
|
@LoganDark I think the point is that, you arguing for this feature in Alacritty is evidence other applications should also have the option to include this feature. Since it's not terminal specific, winit seems like a logical place to implement it for everyone. |
|
I'd be glad to open an issue on the winit repo and link it here. Hell, I could even be one of the people to contribute to such a feature, both brainstorming and the code itself. |
and others
Honestly it's kind of sad that every application needs to support this explicitly, but:
I have a trackpad, is it possible for alacritty to support inertial scrolling? i.e. flick across the trackpad and the output keeps scrolling up for a few seconds.
This is a LIFE SAVER for scrolling really long outputs, and it's a shame alacritty does not support it at the moment, forcing me to make 16 movements across my trackpad. Yes, sixteen. That is not an exaggeration, I actually counted it.
Using Arch Linux with X11/Xinput2 (not sure what alacritty supports, but xinput2 is the way to go for trackpads)
The text was updated successfully, but these errors were encountered: