My personal preference would be to integrate into KGlobalAccel. Also mouse shortcuts, etc.

*** Bug 431356 has been marked as a duplicate of this bug. ***

*** Bug 458237 has been marked as a duplicate of this bug. ***

Sadly that in the most configurable DE touchpad gestures couldn'be customized;(

(In reply to Petrov Egor from comment #4)
> Sadly that in the most configurable DE touchpad gestures couldn'be
> customized;(

I cannot help it but agree on this one.

*** Bug 443022 has been marked as a duplicate of this bug. ***

*** Bug 482030 has been marked as a duplicate of this bug. ***

With the Plasma 6 dust settling, this is a part I feel needs priority for laptop-heavy use. My use case is using three-finger navigation to move between virtual desktops+grid, and four fingers for brightness+volume control (all through touchegg formerly). 

My touchegg config ported right over to libinput-gestures for Wayland, but the native gestures continue to move between desktops when libinput-gestures are activated. Is it feasible to implement a toggle for the hardcoded 3-4 finger desktop switching, so users can substitute their own gesture handlers in the interim? 

It may warrant an extra bug report as well, but the native gestures are VERY sensitive. Compared with a Macbook's three-finger gestures that smoothly transition between virtual desktops (with intertia), the current Wayland gestures are too fast unless you only move your fingers a few millimeters, and then there's still no smooth inertia as you let go.

I want 3 fingers gestures for grid aswell, until there is a configuration switch, as a workaround I successfully patched the kwin_wayland binary to change 4 fingers to 3 fingers. I describes the steps here https://blog.izissise.net/posts/kwin-gesture-patch/

sorry to pile on, really like KDE Plasma. the trackpad gestures just aren't configurable. i don't mind the 4 finger swiping, but 4 finger swiping down to pull up an overview isn't intuitive. the way Apply implements it is intuitive, in my opinion, anyway. 3 fingers swiping up gets you the overview, then 3 finger swipe back down returns to normal view. 3 fingers left or right moves desktops. the number of fingers isn't the issue, really (although 3 would be nice), it's the direction of the swipes. but just to have them freely configurable would be the best outcome. thanks for all the work y'all do!

I'd like to echo @breakingspell's comment for the plasma 6 upgrade. This is a serious issue for my laptop usage, I use my own custom gestures for almost all navigation (via libinput-gestures), and the current system breaks my entire config.

Please add an off button in settings. I don't care about extensibility in the short term, power users can manage their own gestures with other tools for now, but only once we can turn off the current system.

Even if other work is pending, at least add an on/off toggle in 'Settings -> Mouse & Touchpad -> Touchpad' for the next release.

I looked at the source, and the gesture seems to be registered by these lines:

https://invent.kde.org/plasma/kwin/-/blob/master/src/virtualdesktops.cpp#L772

If someone could wrap them with an if-statement that checks a toggle, that might be enough? I don't know how to contribute this myself or I would.

(In reply to Ima S from comment #12)
> I looked at the source, and the gesture seems to be registered by these
> lines:
> 
> https://invent.kde.org/plasma/kwin/-/blob/master/src/virtualdesktops.cpp#L772
> 
> If someone could wrap them with an if-statement that checks a toggle, that
> might be enough? I don't know how to contribute this myself or I would.

Thanks for scoping out where these are! I was looking in the entirely wrong place (src/gestures.cpp) before giving up last month and falling back to X11 for a few other reasons. 

Did a quick test by just commenting out the hardcoded instances of registerTouchpadSwipeShortcut() in virtualdesktops.cpp, it does prevent the gestures from triggering. To note, the 4-finger up-down gestures are defined in overvieweffect.cpp as addTouchpadSwipeGesture(): 
https://invent.kde.org/plasma/kwin/-/blob/master/src/plugins/overview/overvieweffect.cpp#L36

Putting the registers behind a config toggle or dummying out doesn't seem like the right solution even for short-term though. The code is spread out among multiple components so it will need to be unified at some point, it'd be worse later on if they're just patched out here. Would it be possible to bring all these Touchpad registers into gestures.cpp, and then configure from there?

*** Bug 454231 has been marked as a duplicate of this bug. ***

*** Bug 487710 has been marked as a duplicate of this bug. ***

*** Bug 490067 has been marked as a duplicate of this bug. ***

*** Bug 491409 has been marked as a duplicate of this bug. ***

Even Windows natively allows customising gestures.  Under Windows, I used to use "three-finger left/right swipe" for "go backward/forward", basically the same as the mouse back/forward buttons. In my opinion, this was really helpful, because I could easily/quickly browser the web, file manager, and even programming IDE's. Gnome does not provide gesture customisation either, but at least there was an extension that allowed me to map "three-finger left/right" to "go forward/backward".

Currently, on Plasma, both three and four-finger swipes do the same thing: switching desktop, and I have to move the mouse pointer to click the back icon on the top-left of the app. Really inconvenient and hurting my wrist. If not full customisation, I wish at least there was some sort of checkbox to use three-finger swipes for "go forward/backward".

I got to this bug because the 3 finger switch between screens seems reversed to me. Awkward to use it. 
Please implement a convenient way to select direction (and even better -- a menu for choice of function) of 3 finger horizontal touchpad swipe!.

Please consider looking into this issue, very awkward for laptop users coming from other OSes (or those coming from DEs that actually allow gesture configuration)

*** Bug 495984 has been marked as a duplicate of this bug. ***

*** Bug 494227 has been marked as a duplicate of this bug. ***