Alexander Mikhaylenko @exalm@floss.social

I want to apologize for this tweet/toot, depending on where you read this. I was in a really bad mood amplified by a sleep deprivation, and should have just not said anything. Hope nobody got offended by that. :(

People using gtk-rs, if I point out an omission in gtk-rs and you immediately take it personally and get all defensive and call me names and say I'm attacking it for no reason, it really doesn't improve my opinion on Rust at all, rather makes you look like a sect. 🤦️

@vancha Well, so far I got one response on twitter, and they couldn't reproduce it: the last delta is like 3 times lower and not like 100 times lower than the others.

The first person*

So if anybody has elantech touchpads, would be helpful if you can provide me some libinput recordings.

So I went ahead and implemented it. But unfortunately, that's still not nearly enough to fix it, so it would be awesome to know if this also happens on other elantech touchpads, or maybe it's something weird on that particular laptop.

Now, of course I'm not the person to have stumbled on this. Kinetic scrolling in GTK dealed with the same issue long before. It tracks a history of scroll deltas from the last 150ms and sums them. This seems like a good solution: we smooth the bad event out.

So, I got a report from a person with an elantech touchpad that the gesture was way too stiff. We did some investigation, and the velocity was like 100 times lower than it should be. And surely enough, it was what I just described: an event with very low deltas at the end.

Previously the swipe trackers I wrote used delta from the last non-(0, 0) event, and the times from the last 2 events. It was good enough at the time, but it means that if there's a scroll event with low, but still not zero deltas at the end of the swipe, things break.

Now, how the swipe looks like? We get lots of scroll events, each of them has time and (x, y) deltas. At the very end we get an event with (0, 0) deltas, and that's a signal to stop tracking, calculate the velocity, and notify the users to start an animation.

So if the velocity is calculated incorrectly, it's not too big deal.

However, with the new approach we actually care a lot about this value, and if it's too low, it might lead to a situation where you swipe very hard and yet scroll just a couple pages instead of like above.

The crucial part here is determining swipe velocity after we lift the fingers. With the old approach we mostly cared about its direction and whether it's high enough or not.

Of course it was also used to determine the animation duration, but it's aggressively clamped.

Context: I'm reworking the swipe trackers in libhandy/gnome-shell/webkitgtk to use a more physics-based approach for deciding whether to finish or cancel swipe, and to optionally allow swiping through more than one page at once for HdyCarousel.

Anybody has an elantech touchpad? I might need help with reproducing a bug with scrolling/gestures :)

People with macbooks: is it possible to switch more than one workspace with a single swipe gesture? I.e. go from 1 to 3 in one motion?

Similarly, what happens if you repeatedly quickly swipe? E.g. swipe 3 times in a row, will it go 1->2->3->4 or will it fly further?

Interesting how Firefox Beta manages to be _much_ less stable than Preview/Nightly. I don't think I ever had a crash with that one.

Umm, this was supposed to be for twitter only, but whatever.