cross-posted from: https://lemmy.ml/post/21519137
I recently switched from a MBP to a Framework 16 as my primary laptop and one thing I immediately noticed was that I was unable to stop kinetic scrolls in Firefox by laying my fingers onto the touchpad. It’d just slide by unimpeded. You could work around this by counter-scrolling a little rather than holding still which is how I’ve been coping with it but it’s suboptimal to say the least.
(As are many things in the Linux touchpad experience. Linux desktop developers really ought to use a macbook for a little to get a sense for how to do this properly.)This was caused by Firefox’ use of GDK3 to implement its windowing and input needs which does not support hold gestures.
GDK4 does support them but, as I understand it, a port of Firefox to GDK4 would be a ton of work and there isn’t really much desire for it as GDK4 doesn’t offer many real advantages over GDK3 as Firefox doesn’t use classical GTK widgets or anything and only really uses it for basic input/output primitives.
A backport to handle hold gestures in GDK3 too was attempted but, in classic GNOME fashion, it was rejected.
The implementation now somehow gets events from the touchpad directly via wayland somehow from what I could gather but if it works, it works.
You can try this out in the latest nightly builds.
This was one of the most annoying things to me switching to Firefox a couple of years ago.
I’ve also been following this bug since switching (back), and have kinetic scroll turned off for the last few years, I somehow got used to linear scrolling – it’s not something that bothers me anymore, but I’ll be happy to switch back now!
Looking through the gitlab, it seems the backport of this hold gesture to GTK3 was rejected for good reason. Seems very unfair to imply it was done out of sheer spite.
It would break a lot, require a new API, and devs reworking a lot of programs.
It’s also completely reasonable just from the POV of not accepting major new features in GTK3 when GTK4 exists.
Devs likely expect GTK3 to be feature-stable, given GTK4 has been out a while and GTK5 work starting soon. It’s at the tail-end of its life.
If somebody wanted a major new feature in Python, for example, I wouldn’t be surprised if the Python team gave it the go-ahead for Python 3 but not Python 2. GTK3 is done, they’re only really doing bug fixes now.
Nobody expects new features to be added to Plasma 5 or Gnome 45.
It’s 100% the right decision not to keep adding features to an old widget toolkit that has been superceded by GTK4 and is almost EoL.
That issue aside… good. Seems like a nice feature.
It would break a lot, require a new API, and devs reworking a lot of programs.
As I understand it, this would have been a perfectly backwards compatible change. You’d only get the events if you explicitly asked for them.
