Add a Gesture option to scroll and switch between open windows, similar to Alt Tab

[capttrousers]

Problem

Alt Tab allows you to hold Alt, and continually press Tab until you get to the open app window you want to switch to, but it doesnt allow you to use the arrow keys. And forces you to hit the correct keys.

Using gestures is a more natural UX, considering people's familiarity with gestures and touch screens with modern smart phones.

Proposal

Add the ability to use 3 or 4 finger Right/Left swipes to scroll through open windows. When using Alt Tab, the currently selected window shows up on top, with the rest being grayed out beneath, while you are still holding Alt, so a similar animation of control could be used.

Once you pick up your fingers, the currently selected app window is now the top window with focus, similar to how letting go of Alt will focus on that window.

The "Scroll Through Open Windows" option would be in the drop down of the Gestures settings page, for Swipe Horizontally, 3 or 4 fingers. Now there is just one option for switch to workspace, but this would add an additional option to that drop down menu.

Stopping and scrolling the other way should scroll naturally, both left and right and back and so forth, without picking up your fingers.

Prior Art (Optional)

No response

[cassidyjames]

I think this makes sense; the bigger question for me is if it would be possible to have touchégg and Gala coordinate that gesture. cc @JoseExposito

I also imagine we'd have this off by default so as to not overload the left/right swipe gestures, so there's a question design-wise if we want to invest in a non-default behavior.

As for prior art, I believe Windows has a window-switching gesture like this. It would be worth double-checking how it works so we know if we want to match its behavior for familiarity.

[JoseExposito]

This is already possible just with Touchégg, check example 2 or add the shortcuts with Touché for testing:
https://github.com/JoseExposito/touchegg#keyboard-shortcut-send_keys

The user experience can be improved by, for example, not allowing to jump to the start of the window list from the end, but that should give you enough to test and get a good idea of the raw edges we'd need to polish.

In my experience implementing this kind of "repeat action" gestures it's important to:

1. Keep the physical distance you need to move your fingers to jump one item constant.
   For example, imagine 2 scenarios where we have 2 and 5 windows open. It's important that the amount of movement required in both scenarios to change from item 1 to 2 is the same for muscle memory.

2. I found that 10 steps are the sweet spot. Allowing more steps makes selecting items precisely very difficult, specially on small touchpads.
   The problem is handling more than 10 items, in this case, when the user has more than 10 windows open. Personally, I'd not allow to select the window number 11, because of what I explained in 1. and because it will get really difficult to select it precisely.

In case you want to explore other values, change this constant and re-compile:
https://github.com/JoseExposito/touchegg/blob/master/src/actions/repeated-action.cpp#L46

But so far, nobody complained about that hardcoded value.

As for prior art, I believe Windows has a window-switching gesture like this. It would be worth double-checking how it works so we know if we want to match its behavior for familiarity.

Yes, this gesture is enabled by default in Windows 10.

[capttrousers]

Thanks for engaging both of yall!

I had already tried setting this up custom in Touche but there are definitely corner cases and bugs I've hit. For example often times the swipe gesture gets the alt tab behavior stuck, where I've lifted my fingers from the pad and finished the "gesture session" but it is still showing the Alt Tab windows dock thing. It also doesnt work to reverse direction within the same "session", so to scroll forward and back with the fingers remaining on the pad.

Here's the setup I did in the UI:

@JoseExposito I agree with both your points, the swipe distance control to scroll to the next window should feel the same no matter the count of windows I'm scrolling through. And if your experience recommends 10 steps as the max, that seems fine where the user has to scroll right as far as they can, and then start the swipe again from the left of the track pad to continue scrolling to # 11.

There will definitely be a practical limit to the number of windows one could scroll through with a single "session" of the fingers on pad, due to the limited surface area on different trackpads.

The order of the windows should be stable so that kind of scroll in two "sessions" for a lot of windows would work properly.

Also @cassidyjames I agree it'd be off by default, you'd need to go into the Gestures to set this up specifically, but what do you mean by a non default behavior?

[JoseExposito]

@capttrousers here is the right config:

You are probably finding problems, like not being able reverse to Alt+Tab because of the missing fields.

[danirabbit]

I wanted to follow up here that after analyzing results from our recent UI study, it seems like we should have a dbus interface here for getting 1:1 gestures with window switching. This should allow us to both handle the case where touchegg daemon is sending gesture events, but also where we want to forward scroll events from dock items to switch between windows.

For this to work for the dock we need to be able to specify an app ID that we'd like the window manager to switch between windows belonging to that ID

[JoseExposito]

Probably not to be discussed on this issue, but there are Wayland protocols available for these tasks. I can quickly think of layer shell and toplevel management. I think that Kwin uses similar protocols as well, but I'm not familiar with its code base.

It's probably worth it to explore this option and collaborate upstream if possible rather than implementing our custom API.