Behavior of focus-follows-mouse when switching workspace using touchpad gesture

[tyressk]

Given for example two applications in a workspace when focus-follows-mouse is enabled, using the touchpad gesture to swipe to the next workspace always gives the focus to the rightmost full window when swiping right, and the leftmost window when swiping left.

If you wanted to focus on the window currently under the mouse pointer, you'd need to click on it or move the mouse pointer to an empty space and then back.

I think it would be nice to have the choice to consistently just give focus on whatever is under the mouse pointer.

[YaLTeR]

using the touchpad gesture to swipe to the next workspace always gives the focus to the rightmost full window when swiping right, and the leftmost window when swiping left

But switching workspaces is swiping up/down, not right/left? When swiping right/left my idea was that you swipe as much as needed to reach some window, so focusing the furthest window into that direction makes sense.

[tyressk]

Ah that's right about the workspaces term part, sorry...but it's still true when I move workspaces.

So my use case is, say for example I have 3 apps, a terminal (50% of the screen), and a text editor (50% of the screen) on workspace 1, and a browser (100% of the screen) on workspace 2 below it. I want to look at the browser on workspace 2 to check a wiki, and go back to workspace 1 to continue coding. For workspace 1, the focus remains on the last focused item. Ideally for me it would focus on where the mouse is if it has focus-follows-mouse, even if they were all in the same workspace, because my gaze kind of follows the mouse instead of looking at the focus ring because I assume it focuses on wherever it's on. Does this go against any sort of usage idea for Niri?

[YaLTeR]

Workspaces remember their focused window, yeah. I think this makes more sense, especially with keyboard navigation: you might work on one workspace, and quickly switch back and forth with a second workspace where you have a particular window focused, and you expect it to stay focused instead of changing to wherever your mouse pointer happens to end up (you used the mouse pointer on your main workspace, without thinking which window on the second workspace it would overlap).

I guess when using the vertical touchpad swipe or a Mod+scroll wheel bind, there is an argument to trigger focus-follows-mouse for the new workspace, since those are more mouse pointer focused gestures, so to say. But for keyboard I think the current behavior is better.

[tyressk]

I guess when using the vertical touchpad swipe or a Mod+scroll wheel bind, there is an argument to trigger focus-follows-mouse for the new workspace, since those are more mouse pointer focused gestures, so to say. But for keyboard I think the current behavior is better.

That makes sense

[vilhalmer]

I would second having an option for this when using the mouse to switch workspaces, as I often use Mod+scroll wheel and then start typing into the wrong window because my in my brain "cursor over window, therefore focused". This doesn't happen when I use the keyboard to switch, because my reflex is to look for the focus ring when not using the mouse instead of assuming.

Maybe a parameter like focus-follows-mouse include-gestures=true? Then the current behavior doesn't change and the phrasing of the option itself makes the behavior unsurprising.

[YaLTeR]

Hmm

[vilhalmer]

An alternative behavior would be leaving it like it is currently, but triggering the focus change as soon as the mouse is wiggled, instead of needing to cross completely over the border of the window and back. I'm not sure how this would feel on trackpad, but would work well with mousewheel.