6 ms·

Touchpad gestures for Linux apps are being worked on: - Latest update (December 2021): https://www.gitclear.com/blog/linux_touchpad_update_december_2021 https:

Touchpad gestures for Linux apps are being worked on: - Latest update (December 2021): https://www.gitclear.com/blog/linux_touchpad_update_december_2021 https://www.gitclear.com/blog/linux_touchpad_update_december... - HN: https://news.ycombinator.com/item?id=29555822 https://news.ycombinator.com/item?id=29555822 So far, pinch-to-zoom has been implemented in Firefox. (If you are using X11 instead of Wayland, then the environment variable MOZ_USE_XINPUT2=1 needs to be set.) Gestures for back/forward navigation have not been implemented yet (Firefox Bugzilla issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1539730 https://bugzilla.mozilla.org/show_bug.cgi?id=1539730). The project aims to support gestures in other Linux apps, too. If you would like to help fund this project, the developer has a GitHub sponsor page here: https://github.com/sponsors/gitclear https://github.com/sponsors/gitclear

askvictor 5y ago
What I don't quite get is why this needs a project; it just needs configuration options; for example, two-finger swipes currently map to mouse buttons (buttons 6 and 7 for left/right swiping) which most apps interpret as scrolling (in every direction). I'm about to write a script to remap those to browser back and browser forward actions (after a delay to prevent repeated actions), but I'm so surprised it's not baked into the desktop environment. But thanks for the link, I'll check it out
- smoldesu 5y ago
  > What I don't quite get is why this needs a project If this was MacOS, I'd agree. But on Linux, it's a different hardware landscape. There are hundreds of trackpads that Linux is compatible with, but not every one of them is multitouch (or implements multitouch the same way). Gesture support on Linux has been a long time coming, but that's mostly because getting uniform trackpad support over thousands of laptops is just not a very fast process, whereas on MacOS, Apple can make certain assumptions about the hardware it's running.
  - tinus_hn 5y ago
    It’s more about how on MacOS, Apple gets to dictate what signal that gesture is going to send to the applications and you can’t configure it to send anything else. So either the application recognizes that signal and it works for every system, or it doesn’t and it doesn’t work for every system. This makes it a lot more likely that apps are going to recognize that signal so it works for every system. It’s the paradox of choice.
    - KerrAvon 5y ago
      Not really. On macOS, trackpad swipes produce a series of horizontal scroll events, not a simple back/forward event. An app can do whatever it wants with the scroll events. Safari, when the scroll position is at the end of the horizontal outer edge of the document, does an interactive back/forward animation that tracks your fingers while they remain on the trackpad.
      - tinus_hn 5y ago
        As far as I know you’re supposed to use the NSGestureRecognizer system to recognize this kind of gestures and it’ll automatically make it work like you write. If you try to handle all the events yourself you end up doing a lot of work for probably a worse result.
        jb1991 5y ago
        You are correct.
      - jb1991 5y ago
        > On macOS, trackpad swipes produce a series of horizontal scroll events, not a simple back/forward event. That's not true. On macOS (and also iOS), you subscribe to gesture recognizers (i.e. swipe gestures), not isolated events, which give you easy access to how users interact with macOS without having to analyze (and likely analyze incorrectly) low-level trackpad interaction. You could always choose to look directly at events instead, but if you are trying to get the behavior of a widely-used gesture like swiping forward/back, you will get much more accuracy (and happiness from users, and less dev time) by just recognizing them at a high level, which is what Apple expects.
- deleted 5y ago
  [deleted]
- prometheon1 5y ago
  As a user interested in three-finger middle-click and not interested in two-finger back swiping I have the exact opposite experience. In Windows and Linux clicking the trackpad with 3 fingers causes a middle click, in MacOS this is not an option at all. Moreover, enabling it is apparently a project so difficult that the cheapest solution[0] I could find costs €8 just to add middle click functionality, nothing else. [0]: https://middleclick.app/ https://middleclick.app/

askvictor 5y ago

What I don't quite get is why this needs a project; it just needs configuration options; for example, two-finger swipes currently map to mouse buttons (buttons 6 and 7 for left/right swiping) which most apps interpret as scrolling (in every direction). I'm about to write a script to remap those to browser back and browser forward actions (after a delay to prevent repeated actions), but I'm so surprised it's not baked into the desktop environment. But thanks for the link, I'll check it out

smoldesu 5y ago
> What I don't quite get is why this needs a project If this was MacOS, I'd agree. But on Linux, it's a different hardware landscape. There are hundreds of trackpads that Linux is compatible with, but not every one of them is multitouch (or implements multitouch the same way). Gesture support on Linux has been a long time coming, but that's mostly because getting uniform trackpad support over thousands of laptops is just not a very fast process, whereas on MacOS, Apple can make certain assumptions about the hardware it's running.
- tinus_hn 5y ago
  It’s more about how on MacOS, Apple gets to dictate what signal that gesture is going to send to the applications and you can’t configure it to send anything else. So either the application recognizes that signal and it works for every system, or it doesn’t and it doesn’t work for every system. This makes it a lot more likely that apps are going to recognize that signal so it works for every system. It’s the paradox of choice.
  - KerrAvon 5y ago
    Not really. On macOS, trackpad swipes produce a series of horizontal scroll events, not a simple back/forward event. An app can do whatever it wants with the scroll events. Safari, when the scroll position is at the end of the horizontal outer edge of the document, does an interactive back/forward animation that tracks your fingers while they remain on the trackpad.
    - tinus_hn 5y ago
      As far as I know you’re supposed to use the NSGestureRecognizer system to recognize this kind of gestures and it’ll automatically make it work like you write. If you try to handle all the events yourself you end up doing a lot of work for probably a worse result.
      - jb1991 5y ago
        You are correct.
    - jb1991 5y ago
      > On macOS, trackpad swipes produce a series of horizontal scroll events, not a simple back/forward event. That's not true. On macOS (and also iOS), you subscribe to gesture recognizers (i.e. swipe gestures), not isolated events, which give you easy access to how users interact with macOS without having to analyze (and likely analyze incorrectly) low-level trackpad interaction. You could always choose to look directly at events instead, but if you are trying to get the behavior of a widely-used gesture like swiping forward/back, you will get much more accuracy (and happiness from users, and less dev time) by just recognizing them at a high level, which is what Apple expects.
deleted 5y ago
[deleted]
prometheon1 5y ago
As a user interested in three-finger middle-click and not interested in two-finger back swiping I have the exact opposite experience. In Windows and Linux clicking the trackpad with 3 fingers causes a middle click, in MacOS this is not an option at all. Moreover, enabling it is apparently a project so difficult that the cheapest solution[0] I could find costs €8 just to add middle click functionality, nothing else. [0]: https://middleclick.app/ https://middleclick.app/