Linux Touchpad like Macbook Update: Touchpad gestures in Qt, Gimp, Firefox and X server
6 Replies to “Linux Touchpad like Macbook Update: Touchpad gestures in Qt, Gimp, Firefox and X server”
About a year ago I started working on smooth scroll implementation for GTK. The code can be found here: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/1117 The basic idea is interpolating the input events to the screen refresh. IIUC something similar is done by Android in order to achieve “butter smooth” interaction.
I no longer have the time to maintain that, and upstreaming the code has met with some resistance. However the problem is well understood and I think that the solution is sensible. If you can take over that effort, it could improve another aspect of the touchpad “feel”.
Note that similar effort is required on the compositor side, for getting smooth shell-based stick-to-finger animations.
If you are interested then please contact me at oigevald+gitlab at gmail, and I’ll be happy to explain what I did and what I think has to be done.
Something to note, Vscode doesn’t really use GTK for input handling in a lot of ways, and because of its electron base is actually dependent on getting input working in Chrom(e/ium) first since electron is basically just a slightly modified Chromium instance. Same goes for Brave.
In my opinion, out of the three efforts Qt and KDE should take priority. Most of the Linux community is in the final phase of the transition from X11 to Wayland, so while it’d be nice to have gestures and better trackpad support there (and apps like Firefox still wouldn’t provide the best experience on X11 still), Wayland should take priority. And Gimp, while very popular, would not benefit from better trackpad support as much as a DE like KDE would.
btw this the bug tracking the addition of touchpad gestures for KDE is at the following link https://bugs.kde.org/show_bug.cgi?id=401479 and there has been some discussion here https://phabricator.kde.org/T5330 in the past.
Well, as stated https://gitlab.gnome.org/GNOME/gtk/-/issues/3631, there should be a calculation mechanism which are distinct for every input device. Right now, all of them are same, thus the scrolling with touchpad is so uncontrollable. Scroll unit calculation is pretty weird on GTK.
For Chrome/Chromium I think adding touchpad support should be relatively straightforward as “touch” support already supports zooming-in to the page with two fingers, and swiping back with one / or two fingers. I have a Thinkpad with a touchscreen (Wacom) and that works fine when directly execution on the screen, but not on the touchpad. Maybe just a matter of sending a certain input signal to the browser?
For Mutter I think one thing I noticed when trying a MBP recently:
– Animation speed is directly tied to the movement, and always cancellable. That gives a very ‘direct’, and kinetic feel (because you can also “throw” the windows up and get some inertia in the movement.
– One can start a 3 finger drag up, and continue that dragging motion with two or one finger (it’s still a 3-finger motion).
About a year ago I started working on smooth scroll implementation for GTK. The code can be found here: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/1117 The basic idea is interpolating the input events to the screen refresh. IIUC something similar is done by Android in order to achieve “butter smooth” interaction.
I no longer have the time to maintain that, and upstreaming the code has met with some resistance. However the problem is well understood and I think that the solution is sensible. If you can take over that effort, it could improve another aspect of the touchpad “feel”.
Note that similar effort is required on the compositor side, for getting smooth shell-based stick-to-finger animations.
If you are interested then please contact me at oigevald+gitlab at gmail, and I’ll be happy to explain what I did and what I think has to be done.
Thanks for taking lead on this topic!
Something to note, Vscode doesn’t really use GTK for input handling in a lot of ways, and because of its electron base is actually dependent on getting input working in Chrom(e/ium) first since electron is basically just a slightly modified Chromium instance. Same goes for Brave.
In my opinion, out of the three efforts Qt and KDE should take priority. Most of the Linux community is in the final phase of the transition from X11 to Wayland, so while it’d be nice to have gestures and better trackpad support there (and apps like Firefox still wouldn’t provide the best experience on X11 still), Wayland should take priority. And Gimp, while very popular, would not benefit from better trackpad support as much as a DE like KDE would.
btw this the bug tracking the addition of touchpad gestures for KDE is at the following link https://bugs.kde.org/show_bug.cgi?id=401479 and there has been some discussion here https://phabricator.kde.org/T5330 in the past.
Well, as stated https://gitlab.gnome.org/GNOME/gtk/-/issues/3631, there should be a calculation mechanism which are distinct for every input device. Right now, all of them are same, thus the scrolling with touchpad is so uncontrollable. Scroll unit calculation is pretty weird on GTK.
For Chrome/Chromium I think adding touchpad support should be relatively straightforward as “touch” support already supports zooming-in to the page with two fingers, and swiping back with one / or two fingers. I have a Thinkpad with a touchscreen (Wacom) and that works fine when directly execution on the screen, but not on the touchpad. Maybe just a matter of sending a certain input signal to the browser?
For Mutter I think one thing I noticed when trying a MBP recently:
– Animation speed is directly tied to the movement, and always cancellable. That gives a very ‘direct’, and kinetic feel (because you can also “throw” the windows up and get some inertia in the movement.
– One can start a 3 finger drag up, and continue that dragging motion with two or one finger (it’s still a 3-finger motion).
Thanks for working on this!