Kwin effect for trackpad gestures
Open, Needs TriagePublic

zzag added a subscriber: zzag.Apr 15 2019, 10:46 PM

What is the purpose of this effect?

I would assume the purpose of the effect is visualize an in progress trackpad gesture. So for example, when you're swiping with 4 fingers to change your desktop, the effect could already start moving your desktop by a bit, to indicate you're performing a gesture.

As far as I've seen, an effect would need access to how much the gesture has processed, which is currently not possible, as far as I know. (I only have seen the Kwin codebase for about 2 hours, so correct me if I'm wrong) .

I've experimented with trying to implement gestures on the slide effect by directly sending the touchpad events to the effect itself, but that seems hacky in a way that it suddenly also would be responsible for actually switching the desktop, instead on relying on the GlobalShortcutManager to do so.

The most clean way in my opinion would be to somehow connect the effect to the progress signal from the SwipeGesture, which is in an InternalGlobalShortcut in the GlobalShortcutManager. If the QAction could have some kind of a progress signal, that would be nice, but on the other hand, might this be misusing the concept of an Action?

But that would only help for the present windows effect and the show grid effect, but not for the effects that only activate when the desktop is actually changed, like the slide effect. Would it be better to hand off the responsibility of actually changing the desktop to an effect? Or should Kwin add an progress parameter to void desktopChanged(int old, int current, EffectWindow *with); in an effect? The latter one keeps the responsibility of changing the desktop with Kwin, but the former one could allow for overscroll effects when you can't move to a desktop on your left, for example.

Anyway, I would really like to help out this task, since it's something that's on my personal wishlist. Since,a s mentioned before, this is the first time I looked at the Kwin, and even KDE, codebase, I might've seen some solutions to those problems over the head or made some mistakes.

Very nice, please feel free!

daljitsi added a subscriber: daljitsi.EditedApr 16 2020, 12:15 PM

Hi, I am just a beginner but would like to contribute to this too as it has been something I wanted in KDE for a long time now(I am a bit sad that this feature request hasn't received much attention). I have had a look at the code and I think the CubeEffect implementation seems like a good example to follow as it handle "continuous" gestures that follow your mouse via void windowInputMouseEvent(QEvent* e). I thought something like this could also be added to the other effects as well (as @cjsoten suggested you could connect a slot to the progress signal from SwipeGesture).
However, I feel like QAction is not the right tool for the job (although I suppose one could hook up an attached property to handle the progress since it is obviously a QObject after all).

One question I have is how are these things generally tested out? Like do you have to rebuild the entire Kwin project and then run it to see the changes you make to an effect or is there a better way?

zzag added a comment.EditedApr 17 2020, 8:07 AM

@cjosten @daljitsi The problem is that VirtualDesktopManager reserves swipe gestures for switching between desktops. We need an API for reserving gestures and some KCM to assign gestures to actions (e.g. switch between virtual desktops, launch a dashboard, etc).

The most clean way in my opinion would be to somehow connect the effect to the progress signal from the SwipeGesture, which is in an InternalGlobalShortcut in the GlobalShortcutManager. If the QAction could have some kind of a progress signal, that would be nice, but on the other hand, might this be misusing the concept of an Action?

Yeah, that's the way I imagined how it would work. :)

I think KGlobalAccel is a good place to implement such things, although take my words with a grain of salt because I have limited knowledge of KGlobalAccel's internals.

But that would only help for the present windows effect and the show grid effect, but not for the effects that only activate when the desktop is actually changed, like the slide effect. Would it be better to hand off the responsibility of actually changing the desktop to an effect? Or should Kwin add an progress parameter to void desktopChanged(int old, int current, EffectWindow *with); in an effect? The latter one keeps the responsibility of changing the desktop with Kwin, but the former one could allow for overscroll effects when you can't move to a desktop on your left, for example.

We could start sliding between virtual desktops prematurely based on the current progress of a swipe gesture, no need to wait for the desktopChanged signal. Of course, this means we need to differentiate between left, top, right, and bottom swipe gestures in order to be able to determine between which desktops we should slide.

Please let us know if you want to help out with this task.

I was trying to work something on it but I got stuck somewhere and I wasn't able to launch Kwin with both a debugger and the libinput backend. I was doing it in a very different way than @zzag suggested and I do believe that way is a better and more extensible to implement it. Right now I don't have the time to implement it, but maybe in a few weeks I might have.

Offtopic: How do I change my email address in Phabricator? I've changed it on identity.kde.org and I've tried to change it within Phabricator, but I can't edit it. I've missed notifications due to this.

EspiDev added a subscriber: EspiDev.Sep 6 2020, 2:26 PM
jgahde added a subscriber: jgahde.Jan 13 2021, 4:31 PM