Unwanted focus-follows-mouse column movement design

[YaLTeR]

Let's collect the focus-follows-mouse unwanted column movement scenarios and possible solutions to figure out what to do with it.

1. User has two outputs. Moving mouse between them will switch focus and scroll the columns on the source output. #490 #378
   1. The column that gets focused is visible by a very thin margin on the side, sometimes 1 px. In this case, it's clearly unwanted to switch focus.
   2. The column that gets focused is visible by a large margin on the side (i.e. it's already half visible). In this case, the focus switch is probably not a big issue.
2. User has one output with a maximized column and gaps or fractional scale. Moving mouse against an edge of the output (e.g. while trying to use a scroll bar) focuses the next column to the side, which is unwanted. #408 #484
   1. With gaps, this can easily happen if the maximized column is SSD whereas the column to the side has CSD shadows sticking out. Then, hovering over the gap is already sufficient to switch focus, because it is in the next window's input region, while there's no current window input region there, since it's using SSD.
   2. This can also happen when all windows use SSD because the next window might be visible by ~1 px.
3. User has one output with several well visible columns, one of which is only partially visible. However, the user is fine with that and doesn't want it to move on mouse over (or even in general). #490 #378

Possible solutions:

• focus-follows-mouse but only for outputs. Solves all of these, but only if you don't need window focus-follows-mouse. I guess it could be added regardless.
• Focus freeze key. I.e. while holding Alt, focus-follows-mouse is paused. Would solve 1, 2 but not 3. Requires manual action which is annoying.
• View freeze key. I.e. while holding Alt, focus still changes, but the view is frozen. Would solve 3 and sort of 2. Requires manual action which is annoying.
• Visibility threshold for focus-follows-mouse. I.e. the window must be more than min(10%, 16 px) visible for focus-follows-mouse to work. Solves 1i and 2 but not 3. Potentially breaks a workflow when people intentionally use struts to switch between maximized columns, but maybe the threshold can be tuned so that this is not a problem.
• focus-follows-mouse only ever automatically focuses windows which are fully visible. More or less the same as visibility threshold 100%. Solves 1, 2 and partially 3.
• Remove CSD shadows from focus-follows-mouse. Solves 2i but not really much else. Potentially breaks focus-follows-mouse on popups sticking out of geometry; not sure if it's entirely possible to separate the two cases.
• Tentative focus: instead of switching the focus right away, focus-follows-mouse makes the window tentatively focused, and the real focus is only switched on some input event that requires it. Solves 1, 2, somewhat but not fully 3. Might be difficult to implement code-wise. Might require extra design (do is-focused window rules use tentative or real focus? etc.)

"Just don't scroll on focus change"—this cannot really work, scrolling the focused window into view is baked into lots of layout operations. It has to be some specific persistent state. For example, interactive resizing can freeze the scrolling because it is a specific state "is interactively resizing". A view freeze key can exist because it is a specific state "the view freeze key is currently pressed". If you want to suggest not scrolling on focus change, suggest what persistent state could be used to temporarily freeze the scrolling.

We don't have to solve everything at once, if a solution works for several of the cases and doesn't break any other behavior, we can still do it, and it will be an improvement.

[sullyj3]

Not sure about multiple outputs, but the solution I like is:

• mouse movement never triggers scroll.
• Only windows which are fully visible can be focused by mouse hover.
• If you want to focus a window which is partially visible with the mouse, you click it, triggering scroll

If I'm understanding you right, I think this is subsumed by your "Visibility threshold" solution, by setting the threshold to 100%.

I really don't like the view/focus freeze key option. It seems like accidental complexity, feels very inelegant to me.

[rempas]

There's a minor problem with click in that you click something inside the window, but I guess it's mostly not an issue

Well, you'll need to click in the edge of your screen to switch to the column or workspace. Clicking inside the window, in the border or, in the gaps (except of course in the most distant part of the gabs that will be the "thin margin"), will just not do anything and the focus will stay in the current window.

[IgnIVertiKalCaD]

Yes, that's a good idea I cited earlier. If you want to focus a window which is partially visible with the mouse, you click it, triggering scroll" is a great solution. It would be a good idea to implement a "space" freeze rather than a keyclick, so that you don't fly to another window that is to the right or left and sticking out slightly. Sort of like, Mod + S and you can no longer move left or right.

[TheZoq2]

I think that idea would work really well for me too!

[YaLTeR]

I'm thinking, rather than visibility threshold, it should be called a scrolling threshold. I.e. no more than 10% (or, in this case, 0%) scrolling should occur upon focus. This is for the most part equivalent to the visibility threshold, but it will work for partially-offscreen floating windows (which do not scroll), and for wider than 100% tiled windows (which do not necessarily scroll, but are below full visibility).

This is how I would implement it either way, so using this scrolling threshold name might make it clearer that this is how it works.

[YaLTeR]

I guess that would also affect center-focused-column "always" where some amount of scrolling always occurs on changing focus horizontally.

[salman-farooq-sh]

For 1ii, maybe some delay before focus is switched?

[salman-farooq-sh]

@YaLTeR I can do it if you want.

[YaLTeR]

I don't think it's a good idea to reduce responsiveness

[salman-farooq-sh]

A very small delay, just enough that the cursor flung quickly to another monitor doesn't cause focus change. Can and should be zero by default. People with multi-monitors can manually opt into it. KDE has this delay option too irc, or at least something similar.

Is there any other solution?

[YaLTeR]

I mean, I just implemented the other solution. The scroll threshold.

[salman-farooq-sh]

Sorry, I was reading that as visibility threshold solution, the 4th in the list at the top. My bad.

[M3t0r]

I think a good way might be to mark partially visible windows for activation on any action.

So when mousing over a fully visible window, it gets focused immediately. When hovering a only partially visible window this gets marked as tentatively focused, and the previously focused window looses that state. Then, when the user does any action that requires focus, like type a key that should be send to a window, or click or something like that, the windows does get focused, moved into full view, and what not. But when the user doesn't do anything other than moving the mouse, it stays only tentatively focused, and the user can move the mouse over that window without shifting the layout and reach a window beyond that on another output or move the mouse back.

You could even say that any input action other than pointer movement would focus the window, even if it's just pressing the meta key to resize the window or something.

This would solve 1 and 2, and probably most of 3. I don't know if this is enough of a "persistent state" to be technically viable, but I think it might be the best solution.

[YaLTeR]

Hmm, also an interesting idea, though I suspect it may complicate the layout code quite a bit. Will add it to the list.

[YaLTeR]

I've implemented the scroll amount threshold in the latest commits. Please give it a try and tell if it works as you expect and solves your issue.

Example to ban all scrolling:

    focus-follows-mouse max-scroll-amount="0%"

[TheZoq2]

Doesn't active-color and inactive-color border already solve this? Or focus ring which is visible only on the focused window?

I don't think so, I want a specific highlight for the window which the mouse is over, but which isn't focused right now

[permezel]

Focus follows mouse should just do that, and nothing more. All this scrolling makes it annoying for me.
I frequently find myself with my full-screen emacs buffer scrolled right 1/2 a screen and the Alacritty window in the left 1/2, say displaying a manual page. When I move the mouse into the right 1/2 to make some alteration to something in emacs, the emacs window scrolls left, filling the display.

I do not understand why the emacs window needs to scroll so as to be 100% visible just because it gets focus. Can someone explain it to me?
I am pretty sure that when I use sway and I have a floating window over some other window I can focus the background window without it raising to the top, using focus-follows-mouse. I don't particularly want to go back to sway. I am liking niri.

[YaLTeR]

Well it's not a floating layout where it's normal to move the window partially off-screen. The point of tiling is to have what you're working on (i.e. the focused window) always visible. I understand it's sometimes annoying, but perhaps that problem should be solved in a different way than sometimes (when?) blocking the scrolling?

[permezel]

If I was smart, I would clone your repo and see if I could make it work as I would like it to work.
Sadly, not so smart. Much easier for me to adopt a different set of expectations. Still, it would be nice to be able to defeat the scrolling of the focused window.

I might then want emacs to slide the full-width emacs view, still within the left 1/2 of the screen, in the case that my insertion point was not visible in the left 1/2, but managing things so as to never run into that is pretty much normal use case.

[rempas]

If I was smart, I would clone your repo and see if I could make it work as I would like it to work. Sadly, not so smart. Much easier for me to adopt a different set of expectations. Still, it would be nice to be able to defeat the scrolling of the focused window.

I might then want emacs to slide the full-width emacs view, still within the left 1/2 of the screen, in the case that my insertion point was not visible in the left 1/2, but managing things so as to never run into that is pretty much normal use case.

You are smart. We all are. It just requires hard work and effort, and you're not willing to put it. No offense, I just like things to be said as they are ;)