Bug 401479 - Feature request: add animations that follow the fingers when performing touchpad gestures
Summary: Feature request: add animations that follow the fingers when performing touch...
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: effects-various (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR wishlist
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 445896 (view as bug list)
Depends on: 402859
Blocks:
  Show dependency treegraph
 
Reported: 2018-11-27 17:23 UTC by Daljit
Modified: 2022-04-15 00:25 UTC (History)
20 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.25


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daljit 2018-11-27 17:23:59 UTC
Currently in KDE Wayland there are some touchpad gestures that allow the users to switch between desktops, show the desktop grid and present windows view. Now these gestures are great, but there is one problem with them: the UI isn't animated as the user is performing the gestures but the animation is triggered only when the gesture have been "performed" (user lifts finger). In this way, the user doesn't get immediate feedback (which is not a great user experience) and the gesture feels like a hack that is performing a keyboard shortcut. Gnome has implemented this already for desktop switching https://www.reddit.com/r/gnome/comments/9hsw0p/nice_touchpad_gestures_improvement_in_gnome_330/. On Mac OS, which provides the best touchpad experience of any OS, this has been implemented from years and it would be amazing if we could add this to KDE.
Comment 1 Nate Graham 2018-11-27 18:58:21 UTC
This would indeed be nice. However such a vague bug is probably not actionable. Can you list the specific effects that you'd like this to be implemented for, and how?
Comment 2 Daljit 2018-11-27 19:57:03 UTC
Yes, sure. In my opinion, there are 3 essential effects that need to be animated:

1. Desktop Switching. Currently (I have tested Plasma 5.12 Wayland) if you swipe with 4 fingers left or right it switches between different workspaces (I think the current default "direction" of switching is "incorrect" because when the user swipes from left --->right, it switches to the next desktop, but it should switch to the previous desktop, this is the default behaviour on Windows 10 and Mac OS). As for the animation the desktops should slide horizontally as the user moves their fingers on their touchpad (NOTE: this might be slightly inconsistent if the user has for example their "Desktop Grid" organized in 2x2 grid, so when the user is on Desktop 2 swiping to the next desktop would still have a slide animation suggesting that Desktop 3 is adjacent to Desktop 2 when it's actually on a new row). 

2. Desktop Grid. When the user swipe up with 4 fingers the desktop grid should be shown (again already implemented in Wayland). The desktop should "zoom out" as the user slides their fingers upwards and if the they decide to stop in the middle of the gesture and start swiping downwards, the grid should start to "zoom in" on the current desktop. The current animation does exactly this but the ui doesn't follow the fingers, but (merely) a command is triggered when a gesture is detected.

3. Present Windows. When the user swipe downwards with 4 the "Present Windows" should be shown. The current animation to show this view is nice but it just needs to follow the user's fingers (current window zoom out as the user swipe downwards and other windows starts to show up and reverse the animation if user decides to cancel and start swiping upwards).

So these are three fundamental gestures I would like to be animated. As you are probably aware, these gestures are already implemented in the Wayland session of Plasma 5, all that is needed is modify the experience so that the UI follows the user's fingers on the trackpad. Also I have suggested these gestures to be implemented using 4-finger detection because I believe it to be the "safest" option, but they could also be implemented with 3 fingers. Additionally, some other gestures could be added in a similar way maybe differentiating between 3 fingers and 4 fingers swipe, e.g. 3-finger horizontal swipe to switch between current windows like an alt-tab (Windows 10 does this https://youtu.be/cN-Y4LR5r-8?t=53) and 4-fingers horizontal swipe to switch between desktops. Also multifingers taps could be added. However, for the moment I believe the three effect I just described should be prioritised.
Comment 3 Nate Graham 2018-11-27 21:29:35 UTC
Thanks, that makes sense and I think it's a reasonable request. The macOS implementation of this that I'm familiar with is really, really nice.
Comment 4 Daljit 2018-11-27 22:47:05 UTC
Yeah that is true, Mac OS really has the best touchpad implementation. In terms of coding is the implementation of these animations easy or it requires the rewriting of how the current animation system is implemented?
Comment 5 Vlad Zahorodnii 2018-11-27 22:51:03 UTC
(In reply to daljit97 from comment #4)
> Yeah that is true, Mac OS really has the best touchpad implementation. In
> terms of coding is the implementation of these animations easy or it
> requires the rewriting of how the current animation system is implemented?

Currently, we don't have API for such things so one can't give precise estimate of how much work it would take.
Comment 6 Martin Flöser 2018-11-28 05:15:57 UTC
(In reply to Vlad Zagorodniy from comment #5)
> (In reply to daljit97 from comment #4)
> > Yeah that is true, Mac OS really has the best touchpad implementation. In
> > terms of coding is the implementation of these animations easy or it
> > requires the rewriting of how the current animation system is implemented?
> 
> Currently, we don't have API for such things so one can't give precise
> estimate of how much work it would take.

We have an example though: cube slide effect can start rotating while moving a window.
Comment 7 Daljit 2019-06-28 12:09:27 UTC
Has there been any update/discussion on this?
Comment 8 Vlad Zahorodnii 2019-06-28 12:14:56 UTC
No.
Comment 9 Sawyer Bergeron 2019-06-28 12:18:36 UTC
(In reply to daljit97 from comment #7)
> Has there been any update/discussion on this?

I've been personally peeking around a bit as to how this could be hooked up, it looks like most of what needs to happen is already there, but I haven't seen much discussion. AFAIK the Phabricator entry tracking this hasn't been touched in a little while, though.

@kwin maintainers: if no one is working on this at the moment then I'm happy to try to pick it up, but progress is probably gonna be a bit slow.
Comment 10 Nate Graham 2019-06-28 12:56:43 UTC
In general, you don't need to ask permission to start working on something. Even if you end up duplicating work already in progress, it can be valuable to see how different people have chosen to implement a feature, which can lead to either one improving their code based on novel techniques used by the other that they hadn't considered.
Comment 11 Patrick Aldis 2020-02-01 11:22:07 UTC
(In reply to Sawyer Bergeron from comment #9)
> (In reply to daljit97 from comment #7)
> > Has there been any update/discussion on this?
> 
> I've been personally peeking around a bit as to how this could be hooked up,
> it looks like most of what needs to happen is already there, but I haven't
> seen much discussion. AFAIK the Phabricator entry tracking this hasn't been
> touched in a little while, though.
> 
> @kwin maintainers: if no one is working on this at the moment then I'm happy
> to try to pick it up, but progress is probably gonna be a bit slow.

Any luck?
Comment 12 Sugata Roy 2020-06-03 11:52:18 UTC
Any updates on this?
Comment 13 Daljit 2020-06-03 16:12:25 UTC
There has been talk about this over here https://phabricator.kde.org/T5330. There doesn't seem too much activity on this. I have looked at the code a bit, but I am not familiar with the KDE codebase at all. Furthermore, there is no documentation on how Kwin animations are implemented and the code seems as my experience is limited (I spent days just figuring out how gestures are delivered to the animation system until I saw some blog posts by Martin Flöser that helped a lot). However, I don't think I have the expertise and time to do too much although I might attempt this sometimes again.
Comment 14 Vlad Zahorodnii 2020-06-05 07:09:04 UTC
As far as I know, no one is currently working on this. In to implement this feature, we need an infrastructure for registering global gestures, e.g. swipe gestures in different gestures, pinch gestures, long press gestures, etc. In other words, we need a KGlobalAccel for global gestures. Once we have that, the slide effect could lookup a gesture by the corresponding action name and start monitoring the progress of the gesture.

KWin/Wayland has some infrastructure for registering global gestures, but it's not suitable for our making animations that follow fingers. Furthermore, I don't see why global gestures must be locked to the Wayland session. The touch stuff has been added in XI2.2, so we could just establish a passive touch grab, pass touch events through gesture recognizers, and accept or reject touch events based on state of the recognizers.

A KGlobalAccel for global gestures is do-able. One just has to spend a lot of time on writing gesture recognizers and polishing the communication protocol between clients and the gestures daemon. Qt has some gesture recogrnizers but we can't use them unfortunately because they are private and afaik they can't be used for recognizing gestures with more than 2 fingers.
Comment 15 Vlad Zahorodnii 2020-06-05 07:09:34 UTC
In order to implement this feature*
Comment 16 Mustafa YAMAN 2020-09-05 15:47:16 UTC
Please I need this to use KDE its only reason why I'm using gnome...
Comment 17 Daljit 2021-02-15 15:52:30 UTC
I can see there has been some news on this here https://bill.harding.blog/2021/02/11/linux-touchpad-like-a-mac-update-firefox-gesture-support-goes-live/ and I can see some discussions on the Qt mailing list https://lists.qt-project.org/pipermail/development/2020-December/040718.html.
Is the plan to wait until gesture recognition is added in Qt itself and then implement in KWin?
Comment 18 Nate Graham 2021-06-16 20:26:43 UTC
This is in progress! See https://invent.kde.org/plasma/kwin/-/merge_requests/1059
Comment 19 Nate Graham 2021-11-23 17:25:09 UTC
*** Bug 445896 has been marked as a duplicate of this bug. ***
Comment 20 Eric Edlund 2022-02-14 23:56:50 UTC
I'm working on implementing this right now, hopefully (probably) done for plasma 5.25. whatever's next...
https://invent.kde.org/plasma/kwin/-/merge_requests/1980
Comment 21 Eric Edlund 2022-03-19 13:34:54 UTC
Git commit 3c557be70785a293d8d56a935530665fe4daf6ab by Eric Edlund.
Committed on 19/03/2022 at 13:19.
Pushed by ericedlund into branch 'master'.

rework of slide effect internals

Fixed a bunch of bugs and polished the slide effect.
Plugged the slide effect into the new VirtualDesktopManager interface desktopChanging() to allow for mac os style desktop switching.
Related: bug 448419

M  +291  -167  src/effects/slide/slide.cpp
M  +45   -11   src/effects/slide/slide.h

https://invent.kde.org/plasma/kwin/commit/3c557be70785a293d8d56a935530665fe4daf6ab
Comment 22 Nate Graham 2022-04-08 14:17:28 UTC
Git commit 170b0e9aa003014c2ae604fc2c5b1eb97341646b by Nate Graham, on behalf of Marco Martin.
Committed on 08/04/2022 at 14:17.
Pushed by ngraham into branch 'master'.

effects/overview: Support touchpad realtime activation

Now it follows your fingers when you do a four-finger swipe up to activate it.

M  +30   -2    src/effects/overview/overvieweffect.cpp
M  +1    -0    src/effects/overview/overvieweffect.h
M  +9    -1    src/effects/presentwindows/presentwindows.cpp

https://invent.kde.org/plasma/kwin/commit/170b0e9aa003014c2ae604fc2c5b1eb97341646b
Comment 23 Nate Graham 2022-04-15 00:24:52 UTC
Git commit 003c820e0047337aaf714ea765f15b2b1e9a9d26 by Nate Graham, on behalf of Eric Edlund.
Committed on 15/04/2022 at 00:09.
Pushed by ngraham into branch 'master'.

rework of slide effect internals

Fixed a bunch of bugs and polished the slide effect.
Plugged the slide effect into the new VirtualDesktopManager interface desktopChanging() to allow for mac os style desktop switching.
Related: bug 448419

M  +267  -123  src/effects/slide/slide.cpp
M  +45   -11   src/effects/slide/slide.h
M  +1    -1    src/virtualdesktops.cpp

https://invent.kde.org/plasma/kwin/commit/003c820e0047337aaf714ea765f15b2b1e9a9d26